Hi, Juanjo
Thanks for taking my patch. I spent a little more time on checking ECL's "contrib/sockets/sockets.lisp", and it seems that things are not that serious as my first view. Only two buggy sockopt related functions are found:
[Bug Description]
* GET-SOCKOPT-BOOL returns wrong value (always T or throw a error)
I've explained the reason (variable of actual value is dropped).
* SET-SOCKOPT-BOOL returns wrong value (always T or throw a error)
I believe this is a typo.
[Affected public interfaces]
SOCKOPT-REUSE-ADDRESS, SOCKOPT-KEEP-ALIVE, SOCKET-DONT-ROUTE, SOCKET- LINGER, SOCKOPT-REUSE-PORT and SOCKOPT-TCP-NODELAY. (Package SB-BSD- SOCKETS)
[Solution]
I've made a new, small patch (as in attach) to "sockets.lisp" which fixed all above issues and now ECL behaves exactly the same as SBCL when accessing above socket options:
(setq socket (make-instance 'sb-bsd-sockets:inet-
socket :type :stream :protocol :tcp)) #<SB-BSD-SOCKETS:INET-SOCKET descriptor 3 4320793344>
(sb-bsd-sockets::sockopt-tcp-nodelay socket)
NIL
(setf (sb-bsd-sockets::sockopt-tcp-nodelay socket) t)
T
(sb-bsd-sockets::sockopt-tcp-nodelay socket)
T
For the original bug which Leslie P. Polzer report to USOCKET project, it's also fixed without touching USOCKET source code (if this new patch applied), I believe.
Regards,
Chun Tian (binghe)
在 2009-10-18，1:58， Juan Jose Garcia-Ripoll 写道：
2009/10/17 Chun Tian binghe.lisp@gmail.com:
For a summary, I'll suggest Juanjo merge my version first (or Mattew's version with the number "6" replaced to "IPPROTO_TCP"). I'll see how far I can go from now on.
Thanks a lot for your help in debugging this and the other problems!
I have just committed your patch --it also has the advantage that the level is explicit, just like in SBCL's code---. It is available in both the GIT and CVS repositories.
Juanjo
-- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com
I added that fix as well. Thanks again a lot for taking time to look into this!
Juanjo
2009/10/17 Chun Tian binghe.lisp@gmail.com:
Hi, Juanjo
Thanks for taking my patch. I spent a little more time on checking ECL's "contrib/sockets/sockets.lisp", and it seems that things are not that serious as my first view. Only two buggy sockopt related functions are found:
[Bug Description]
- GET-SOCKOPT-BOOL returns wrong value (always T or throw a error)
I've explained the reason (variable of actual value is dropped).
- SET-SOCKOPT-BOOL returns wrong value (always T or throw a error)
I believe this is a typo.
[Affected public interfaces]
SOCKOPT-REUSE-ADDRESS, SOCKOPT-KEEP-ALIVE, SOCKET-DONT-ROUTE, SOCKET-LINGER, SOCKOPT-REUSE-PORT and SOCKOPT-TCP-NODELAY. (Package SB-BSD-SOCKETS)
[Solution]
I've made a new, small patch (as in attach) to "sockets.lisp" which fixed all above issues and now ECL behaves exactly the same as SBCL when accessing above socket options:
(setq socket (make-instance 'sb-bsd-sockets:inet-socket :type :stream :protocol :tcp))
#<SB-BSD-SOCKETS:INET-SOCKET descriptor 3 4320793344>
(sb-bsd-sockets::sockopt-tcp-nodelay socket)
NIL
(setf (sb-bsd-sockets::sockopt-tcp-nodelay socket) t)
T
(sb-bsd-sockets::sockopt-tcp-nodelay socket)
T
For the original bug which Leslie P. Polzer report to USOCKET project, it's also fixed without touching USOCKET source code (if this new patch applied), I believe.
Regards,
Chun Tian (binghe)
在 2009-10-18，1:58， Juan Jose Garcia-Ripoll 写道：
2009/10/17 Chun Tian binghe.lisp@gmail.com:
For a summary, I'll suggest Juanjo merge my version first (or Mattew's version with the number "6" replaced to "IPPROTO_TCP"). I'll see how far I can go from now on.
Thanks a lot for your help in debugging this and the other problems!
I have just committed your patch --it also has the advantage that the level is explicit, just like in SBCL's code---. It is available in both the GIT and CVS repositories.
Juanjo
-- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com
Juan Jose Garcia-Ripoll wrote:
I added that fix as well. Thanks again a lot for taking time to look into this!
I'd also like to extend my thanks to everyone involved for the exceptionally fast and professional solution.
Proprietary support can hardly compete.
Leslie
-
Chun Tian -
Juan Jose Garcia-Ripoll -
Leslie P. Polzer