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

[Chun Tian (binghe)]

Hi, Nikodemus

在 2011-3-28，04:26， Nikodemus Siivola 写道：

> 2011/3/27 Chun Tian (binghe) <binghe.lisp at gmail.com>:
> 
>> Well, I think the TIMEOUT keyword arguments on SOCKET-CONNECT currently has following meanings:
>> 
>> 1. When doing TCP work, it means a "connection timeout";
>> 2. When doing UCP work, it sets the default "read timeout" (because "connection timeout" is meaningless for UDP);
> 
> For SBCL backend at least this is not correct.

I see. But for other backends (at least LW and CCL), seems correct.

Among all CL platforms, Clozure CL have the most feature-rich networking API. Its MAKE-SOCKET [1] provided three keyword arguments: INPUT-TIMEOUT, OUTPUT-TIMEOUT and CONNECT-TIMEOUT, and an additional DEADLINE.  LispWorks only has TCP support, but its OPEN-TCP-STREAM [2] also provided three keyword arguments: READ-TIMEOUT, WRITE-TIMEOUT, and TIMEOUT.

[1] http://ccl.clozure.com/manual/chapter7.2.html
[2] http://www.lispworks.com/documentation/lw60/LW/html/lw-553.htm#pgfId-888355

> 
> There :TIMEOUT is a read timeout for any single blocking read from the
> socket. Connections and writes are unaffected -- though SBCL changes
> may apply the timeouts to writes as well.
> 
> Waiting for a connection is not affected -- but adding support for
> that is pretty easy.

Then I suggest adding these missing part, at lest adjust the meaning of "TIMEOUT" argument of SOCKET-MAKE-STREAM into "connection timeout", and add READ-TIME / WRITE-TIMEOUT support.

> 
> Sidenote: I haven't really looked at usocket's SBCL backend beyond
> SOCKET-CONNECT prior to this, but a quick peek shows that it's pretty
> cavalier about using SBCL internals. This is not good. Internals
> _will_ change, and then usocket will break. Specifically, SB-UNIX
> package is an internal implementation package -- using it is bad.
> SB-POSIX is the supported POSIX api. Some SB-FOO::BAR stuff in there
> as well. :/

Well, I think maybe the two projects (USOCKET and SBCL) didn't collaborate quite well in past years.  USOCKET authors (at least me) want to support as most versions of SBCL as possible.  This means, if we ask SBCL to add all necessary support to make things on usocket side become trivial, then we will loose support for older SBCL versions.  Sometimes we have to do some dirty work (all around SBCL backend code) to detect if a "feature" exist in a SBCL version...

I admit this is not good, but consider SBCL's current networking API lack of many features, and SBCL's release cycle is too fast to make all in-use SBCL versions quickly become old, I don't think a full rewrite of usocket's SBCL backend is possible at current stage.  But if SBCL official can start to improve its networking part from now on, after maybe one year, or after at least 10 new SBCL releases, maybe we can force switch to a new backend with "good code" without using any internals.

Glad to know your thoughts on this.

Regards,

--binghe

> 
> Cheers,
> 
> -- Nikodemus