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 <[EMAIL PROTECTED]> 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.
_______________________________________________ usocket-devel mailing list usocket-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
