On 24/giu/2013, at 21:14, Tomas Hlavaty <tomas.hlav...@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

Reply via email to