[drakma-devel] [patch] Resubmit drakma timeout for sbcl.

[Daniel Weinreb]

Edi Weitz wrote:

I think this is something that belongs into usocket and not into
Drakma.  I'm not monitoring usocket, but if it had the ability to
optionally specify timeouts and deadlines for those implementations
supporting these features (and making them no-ops on others), I'd
happily integrate that into Drakma.  I don't want to litter Drakma
with conditional expression for various Lisps, though.

and in later mail:
>
> I didn't know that usocket supports timeouts now. 

But in the latest Drakma, in http-request, there is a :deadline
argument, which is passed through to usocket:socket-connect.

Unfortunately, it is specific to CCL (OpenMCL).  Drakma
also knows, for CCL, to set the ccl:stream-deadline of
the stream, too, so that the deadline applies not only
to the connect work itself, but to the entire connection.

This is quite useful for anyone writing a program that
needs to have end-to-end timeouts.  Servers usually
need this more than clients, in my experience.  We
use this in our server for that reason: every request
is given a deadline, and we have to make sure that
anything that might block for input or output will
honor the deadline.

For Lispworks, I see that there is a different set of
keyword arguments, that have "timeout" in their names.

I completely sympathize with your not wanting to
litter Drakma with implemenation-specific code.
It would be good to get as much of this out of
Drakma as possible.  For Lispworks this may
be difficult; I notice that Hunchentoot also needs
to have a lot of Lispworks-specfic code.

However, it looks to me as if usocket:socket-connect
does support a :timeout argument for SBCL,
as well as for CCL (OpenMCL).  Also abcl and mcl,
but not Allegro, cmucl, scl, nor clisp.  Presumably
this is because the underling implementation doens't
support it; like many things, it's not part of the
CL standard.

Erik says, about usocket:

Well, there has been some development in usocket in the direction of
supporting timeouts. On platforms where timeouts are not supported, an
UNSUPPORTED-FEATURE condition is signalled. If that's ignored,
everything should just continue without the timeout settings.


Indeed, if you look at socket-connect for SBCL,if the
deadline argument is not null, it signals a condition
to say that the feature is unsupported.  socket-connect does,
however, support the :timeout argument.

I don't know SBCL can't accept :deadline,
subtract from it the current time, and then use that
as a :timeout, but maybe there's a good reason for
that.  The documentation of socket-connect, which is
in the file usocket.lisp, doesn't document all of
the arguments to socket-connect, so I might
be missing something about the semantics.

-- Dan