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