[usocket-devel] ECL problem
Chun Tian
binghe.lisp at gmail.com
Fri Oct 16 19:24:08 UTC 2009
Hi, dear ECL Developers
One of our usocket user found a strange issue of ECL (9.10.2)'s
network function SB-BSD-SOCKETS:SOCKOPT-TCP-NODELAY:
> (describe 'sb-bsd-sockets::sockopt-tcp-nodelay)
SB-BSD-SOCKETS:SOCKOPT-TCP-NODELAY - external symbol in SB-BSD-SOCKETS
package
-----------------------------------------------------------------------------
SB-BSD-SOCKETS:SOCKOPT-TCP-NODELAY
[Function]
-----------------------------------------------------------------------------
On Linux (2.6.18, 2.6.31), it can be read, but changing a socket's
TCP_NODELAY socket option will cause a "Permission denied" error:
> (require :sb-bsd-sockets)
> (setq socket (make-instance 'sb-bsd-sockets:inet-
socket :type :stream :protocol :tcp))
#<SB-BSD-SOCKETS:INET-SOCKET descriptor 3 43107648>
> (sb-bsd-sockets::sockopt-tcp-nodelay socket)
T
> (setf (sb-bsd-sockets::sockopt-tcp-nodelay socket) t)
Sockopt error: Permission denied
Available restarts:
1. (RESTART-TOPLEVEL) Go back to Top-Level REPL.
Broken at SI:BYTECODES. [Evaluation of: (SETF (SB-BSD-SOCKETS:SOCKOPT-
TCP-NODELAY SOCKET) T)] In: #<process SI:TOP-LEVEL 0000000000741f60>.
On Mac OS X (10.6 here), changing a socket's TCP_NODELAY socket option
has no effect (but no error) and default value is T:
> (require :sb-bsd-sockets)
> (setq socket (make-instance 'sb-bsd-sockets:inet-
socket :type :stream :protocol :tcp))
#<SB-BSD-SOCKETS:INET-SOCKET descriptor 3 4321522432>
> (sb-bsd-sockets::sockopt-tcp-nodelay socket)
T
> (setf (sb-bsd-sockets::sockopt-tcp-nodelay socket) nil)
T
> (sb-bsd-sockets::sockopt-tcp-nodelay socket)
T
I also tried SBCL 1.0.31 on Mac OS X, everything is fine there, and
the default TCP_NODELAY value is NIL.
Old (don't know how old) ECL version has no such issue. I think this
is a bug. I'm not familiar with ECL's source code, by checking
"sockets.lisp", I can only find this:
(define-sockopt sockopt-tcp-nodelay "TCP_NODELAY" bool)
I'm thinking, how does ECL build process detect the actual value
behind C macro/constant "TCP_NODELAY" defined in OS's C header file?
(I know SBCL will actually include them to get the actual value of
them). Is there any possibility that ECL 9.10.2 is using an "old"
value of the C macro/constant TCP_NODELAY which caused OS's setsockopt
() function set a wrong flag to current socket fd? Any way, it breaks
usocket package now.
Help needed.
Regards,
Chun Tian (binghe)
>
> Chun Tian wrote:
>
>> What's your OS environment
>
> Linux wintermute 2.6.31-rc9-ARCH-CUSTOM #1 SMP PREEMPT
> Wed Sep 9 15:53:36 CEST 2009
> i686 AMD Phenom(tm) 9600 Quad-Core Processor AuthenticAMD
> GNU/Linux
>
>
>> and ECL build options?
>
> ./configure --build=i686-pc-linux-gnu \
> --prefix=/usr \
> --with-tcp \
> --with-clos-streams \
> --with-serve-event \
> --enable-shared \
> --enable-unicode \
> --enable-boehm=local \
> --enable-threads \
> --with-system-gmp \
> --without-x \
> --without-clx
>
>
>> And can you supply a simply test case code for this issue?
>
> Yes. I load Drakma (1.0) via ASDF and execute
>
> (drakma:http-request "http://www.gnu.org/")
>
>
>> I ask this because I can't reproduce it in my environment (ECL 9.10.2
>> (default build options), Mac OS X 10.6, Latest usocket trunk code).
>> If
>> you can help us re-produce this issue, we'll look into and try to fix
>> it as soon as possible.
>
> Thank you! :)
>
> Leslie
>
> --
> http://www.linkedin.com/in/polzer
>
More information about the usocket-devel
mailing list