[usocket-devel] Proposed wait-for-input API for waiting for input for (one out of) a list of sockets

Erik Huelsmann ehuels at gmail.com
Wed May 9 18:01:35 UTC 2007


I've come to the conclusion that in order to be able to use sockets,
even in the blocking mode which usocket supports now, we need an API
to wait for one or more sockets to become ready for input (or accept()
in case of server sockets). If this call would support time-outs, that
would be even better.

So, I've investigated all supported implementations and -apart from
LispWorks- they all support a
'wait-for-input-on-one-or-more-sockets-with-timeout' api. (I've sent
LispWorks tech support a mail about this, hoping they actually do
provide a function to achieve this.)

As for the API which I think I'll be able to support on all platforms,
it'll look like this:

(defmethod wait-for-input (stream-or-streams &key timeout))
   => (values ready-streams time-remaining-within-timeout)

So, the input is a stream or a list of streams and a real or integer
value timeout (in seconds). It will return the remaining time in the
timeout and the streams ready for reading/accepting.

When the ready-streams list is empty, there are 2 possible situations:
1) We timed out (time-remaining-within-timeout <= 0)
2) We were interrupted while waiting (time-remaining-within-timeout > 0)

Does this API seem acceptable to you?

If not, please tell me so!

BTW: Discussing sockets and event schedulers on #lisp, drewc brought
up that IOLib has an event dispatcher the API which he would really
like to see copied into usocket. I counter proposed we abstract the
api into a general event dispatching mechanism into which many
different libraries can provide their hooks. I don't think that
providing hooks like these is beyond the scope of this project, but I
do think that adding a dispatcher as complex as the one I found in
IOLib is contrary to the short term goal of 'getting a useable
portability library out there'. IOW: I'd love to work on it, but not
before 1.0.

bye,

Erik.



More information about the usocket-devel mailing list