[usocket-devel] IPv6 support in usocket

[Chun Tian (binghe)]

On 24/giu/2013, at 21:14, Tomas Hlavaty <tomas.hlavaty at knowledgetools.de> wrote:

>> I guess you're using Hunchentoot with the usocket emulations based on IOlib, but you didn't implement WAIT-FOR-INPUT, right?   I think that's because IOlib never port their powerful I/O multiplexing interfaces to Windows, so far it only support three OS-provided functions: select (on general Unix), epoll (on Linux) and kqueue (on BSD systems). Maybe you should encourage IOlib author to support "WSAEventSelect", then you don't need to use a timeout arguemnt to socket-accept any more...
> 
> There is only one place in hunchentoot, which depends on a wait-* function and it is to implement timeout on socket-accept because this posix idea of how timeouts are implemented leaks through usocket api iirc.  If you look at many common lisp libraries, they dont have a concept of waiting.  This can be fixed by adding a timeout to the socket-accept so that library code can clearly state its intent without imposing a specific (non-portable) implementation strategy.
> (If you really think wait-* is the right thing, why some usocket functions have the timeout argument and some are supposed to use the wait-* function?)

WAIT-* has the ability to check the readiness status of *multiple* sockets at the same time. Without it you have to create some threads to achieve the same goal.  For application which only operate on single socket, there's no need to call WAIT-* at all, just set a read timeout would be enough. So we provide timeouts for these simple case.  (The question you asked me, can also be directly transferred to OS vendors)

I'm not an network programming expert, so can't easily answer your other questions.  Any way, I don't expect too much from an compatibility layer project like usocket, and I'd better left those complex thing to people who is wring a complex networking software in Lisp, after all they have full access to everything they need from the OS.  If CL implementation's exist stream facility can't afford the special need, it's possible to re-implement them by using Gray streams API.   My duty is to slowly integrate those proven useful things into this compatibility layer and fill the gaps between different backends.

--binghe