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