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.