Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 02 Nov 2009 09:08:53 -0600
From:      Robert Noland <rnoland@FreeBSD.org>
To:        Robert Watson <rwatson@FreeBSD.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Colin Percival <cperciva@FreeBSD.org>
Subject:   Re: svn commit: r198781 - head/lib/libc/sys
Message-ID:  <1257174533.73292.10.camel@balrog.2hip.net>
In-Reply-To: <alpine.BSF.2.00.0911021455080.37561@fledge.watson.org>
References:  <200911020721.nA27LDq1048764@svn.freebsd.org> <alpine.BSF.2.00.0911021455080.37561@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2009-11-02 at 15:00 +0000, Robert Watson wrote:
> On Mon, 2 Nov 2009, Colin Percival wrote:
> 
> >  Attempt to reduce accidental foot-shooting by pointing out that
> >  accept(2)ed sockets do not necessarily inherit O_NONBLOCK from
> >  listening sockets on non-FreeBSD platforms.
> 
> I wonder how much trouble we should go to to document bugs in other systems as 
> non-portabilities for features that work in our system.  This bug in Linux was 
> brought to my attention recently:
> 
>         SO_RCVLOWAT and SO_SNDLOWAT
>                Specify  the  minimum  number  of  bytes in the buffer until the
>                socket layer will pass the data to the protocol (SO_SNDLOWAT) or
>                the  user on receiving (SO_RCVLOWAT).  These two values are ini$B!>(B
>                tialized to 1.  SO_SNDLOWAT is not changeable on Linux (setsock$B!>(B
>                opt(2)  fails  with  the  error  ENOPROTOOPT).   SO_RCVLOWAT  is
>                changeable only since Linux 2.4.  The select(2) and poll(2) sys$B!>(B
>                tem  calls  currently  do not respect the SO_RCVLOWAT setting on
>                Linux, and mark a socket readable when even  a  single  byte  of
>                data is available.  A subsequent read from the socket will block
>                until SO_RCVLOWAT bytes are available.
> 
> I think a more general caution for accept(2) might instead be:
> 
> BUGS
>  	The inheritence of socket options from a listen socket to a newly
>  	accepted socket is inconsistent across protocols, and non-portable.

I don't think we have any business documenting what linux does or does
not do.  As much as I would hate to see someone wasting time finding
this linux bug, we should only document our own behavior.  Hopefully we
at least have a hope of keeping that information accurate.

robert.

> Robert
> 
> >
> >  Feet shot:	cperciva
> >  MFC after:	1 month
> >
> > Modified:
> >  head/lib/libc/sys/accept.2
> >
> > Modified: head/lib/libc/sys/accept.2
> > ==============================================================================
> > --- head/lib/libc/sys/accept.2	Mon Nov  2 06:36:54 2009	(r198780)
> > +++ head/lib/libc/sys/accept.2	Mon Nov  2 07:21:13 2009	(r198781)
> > @@ -126,6 +126,10 @@ new socket.
> > For some applications, performance may be enhanced by using an
> > .Xr accept_filter 9
> > to pre-process incoming connections.
> > +.Pp
> > +Portable programs should not rely on the
> > +.Dv O_NONBLOCK
> > +property being inherited.
> > .Sh RETURN VALUES
> > The call returns \-1 on error.
> > If it succeeds, it returns a non-negative
> >
-- 
Robert Noland <rnoland@FreeBSD.org>
FreeBSD




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1257174533.73292.10.camel>