2011/3/27 Chun Tian (binghe) <binghe.l...@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 _______________________________________________ drakma-devel mailing list drakma-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel
