Hi Hans,
I'm sorry to have to be short in my answer right now - I'm rather busy this week, but I saw you're coming to ECLM this weekend too, so maybe we can talk a bit more there.
On 4/15/08, Hans Hübner hans@huebner.org wrote:
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.
It has been a primary goal to add at least the most basic socket options to usocket from the beginning, so, to me SO_SNDTIMEO and SO_RCVTIMEO are not debatable. Other options might be more in that range, but not these two as I believe they're widely supported by operating systems.
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).
I agree that it would be usefull to add deadlines to the usocket. Doing so could be done in several ways: implementation specific support or returning socket streams based on gray streams which do deadline checking within usocket.
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.
As for supporting deadlines, I would - for now - rather use a specific condition type in relation to the warn or signal call: that way callers can figure out what's actually happening and decide to continue or not.
Bye,
Erik.