[usocket-devel] Patch: Fix SYSCALLS loading on OpenMCL

Hans Hübner hans at huebner.org
Tue Apr 15 11:36:15 UTC 2008


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



More information about the usocket-devel mailing list