[usocket-devel] IPv6 support in usocket

[Tomas Hlavaty]

Hi binghe,

On 06/24/2013 05:25 PM, Chun Tian (binghe) wrote:
> 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.

which is irrelevant for existing common lisp libraries because none use 
this feature.  There are people who try doing that, but so far write 
more or less "trivial" code or toys without addressing the real problems 
with this approach.


>   Without it you have to create some threads to achieve the same goal.

That's exactly how existing common lisp libraries do it, because it 
doesn't break the synchronicity of common lisp.

>    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.

Not true.  hunchentoot _needs_ to use the wait-* function exactly 
because there is currently no other way to timeout on socket-accept.

It is unfortunate that wait-* leaks through the usocket api.  API should 
allow to declare intent (timeout arg) and not to dictate how things are 
implemented (use posix select to timeout).  The current situation seems 
to be up-side down.  I think that the confusion stems from using the 
posix select for all those timeout related use-cases and event 
dispatch.  For portable lisp code, it would be better not to conflate them.

>   So we provide timeouts for these simple case.  (The question you asked me, can also be directly transferred to OS vendors)

Would it be possible to add timeout to the simple case of 
socket-accept?  (And implement it in usocket using wait_* under the hood 
so that it doesnt leak and polute user code?)  That would be a great 
step in the right direction.

Of course it would be also good to accomodate posix select style and 
maybe iocp style but on the other hand, waiting or completion are not 
specific socket features but rather general io event dispatch mechanisms 
so forcing it into a socket api seems a bit questionable.  Maybe the api 
should simply expose the underlying fd/handle only?

> 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

The proven useful things in common lisp are synchronous calls and 
timeouts, not waiting on multiple fds.  If there are any counter-example 
success stories, it would be great to hear about them:-)

Cheers,

Tomas