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 > _______________________________________________ usocket-devel mailing list usocket-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
