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

[Matthew Mondor]

On Sat, 17 Oct 2009 21:42:59 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> 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 at 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 at 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.

Nice.  I just got home now and it's already late again, thanks for
testing yesterday's code (but yes, I managed to sleep a few hours last
night! :)

Another issue I've noticed is the SO_LINGER option which is defined as
using bool but which should use a struct linger:

(from NetBSD GETSOCKOPT(2)):

[...]
     SO_LINGER uses a struct
     linger parameter, defined in <sys/socket.h>, which specifies the desired
     state of the option and the linger interval (see below).
[...]
     SO_LINGER controls the action taken when unsent messages are queued on
     socket and a close(2) is performed.  If the socket promises reliable
     delivery of data and SO_LINGER is set, the system will block the process
     on the close(2) attempt until it is able to transmit the data or until it
     decides it is unable to deliver the information (a timeout period, mea-
     sured in seconds, termed the linger interval, is specified in the
     setsockopt() call when SO_LINGER is requested).  If SO_LINGER is disabled
     and a close(2) is issued, the system will process the close in a manner
     that allows the process to continue as quickly as possible.

Interestingly, I see no SO_LINGER related option at
http://www.sbcl.org/manual/Socket-Options.html#Socket-Options .
Looking at the SBCL source, grovel includes SO_LINGER but there is no
Lisp-exported linger functionality yet (only a comment about it being
special).

The way ours currently work actually causes an error with EINVAL on
NetBSD, since setsockopt(2) is called with SO_LINGER option with a data
size not matching sizeof(struct linger).

We could use integer and a special linger case, which if <= 0 we place
0 in both l_onoff and l_linger, or 1 in l_onoff otherwise with the
supplied integer for l_linger, which would be more useful.  Or, we
could require two values, a boolean and an integer (a list, vector, or
a struct).  Any suggestions?  I think that supporting SO_LINGER is a
nice feature, as I previously used that socket option in some of my C
software.

Thanks,
-- 
Matt