Hi binghe,
On 06/24/2013 05:25 PM, Chun Tian (binghe) wrote:
On 24/giu/2013, at 21:14, Tomas Hlavaty tomas.hlavaty@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