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

[Chun Tian (binghe)]

Hi, Nikodemus

Today I think out another way to solve the SBCL connection timeout issue, I wrap a SB-EXT:WITH-TIMEOUT on SB-BSD-SOCKET:SOCKET-CONNNECT [1], and the result work seems working well:

* (time (ignore-errors (usocket:socket-connect "8.8.8.8" 80 :timeout 3)))

Evaluation took:
  3.010 seconds of real time
  0.010234 seconds of total run time (0.009223 user, 0.001011 system)
  0.33% CPU
  32 lambdas converted
  6,608,582,602 processor cycles
  916,672 bytes consed
  
NIL
#<USOCKET:TIMEOUT-ERROR {1002F34851}>

Do you think this is an acceptable solution?

--binghe

[1] http://trac.common-lisp.net/usocket/changeset/589

在 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.
> 
> 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.
> 
> 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. :/
> 
> Cheers,
> 
> -- Nikodemus