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

[Erik Huelsmann]

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 at 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.