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>