[Ecls-list] [usocket-devel] ECL problem

[Chun Tian]

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
>