Hi Erik,
further investigation showed that the issue is more complex than I had hoped for (certainly I should not hope when it comes to computer related stuff, but I always make that mistake).
What usocket should support in any case is the setting of socket options. This would include setting SO_SNDTIMEO and SO_RCVTIMEO, and that way one would have access to a portable timeout mechanism.
I also think usocket should support access to the deadline mechanism in CCL - I will try to convince Lisp implementors to add the feature to their streams code, but that may or may not be successful. If I can't convince you to support that option, I would propably be able to work around that, but it would be a little painful to have to add system dependencies to application code (Drakma in this case).
In addition, there is the timeout mechanism that SBCL supports on FD-STREAMS. The issue with these is that they are rather SBCL specific and only affect input. Also, timeouts on SBCL's FD-STREAMS cannot be established after the fact without using internally defined SBCL symbols, which is a little painful. SB-BSD-SOCKET does have an interface for setting socket options, but sadly SO_SNDTIMEO and SO_RCVTIMEO can't be set - presumably because of the struct timeval handling involved.
I think having access to socket options is least debatable, so if we could agree that this should be done I would work a little on that. I would like to use the standard identifiers for naming the socket options (SO_SNDTIMEO instead of so-send-timeout or anything else) in order to make it easier to map from standard socket documentation to usocket identifiers.
If you (or anyone else reading) have ideas how implementation specific timeout mechanisms could be added to usocket without having to put implementation specific code into applications, let me know.
Thanks, Hans