svn commit: r198781 - head/lib/libc/sys
Robert Watson
rwatson at FreeBSD.org
Mon Nov 2 15:00:40 UTC 2009
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‐
tialized to 1. SO_SNDLOWAT is not changeable on Linux (setsock‐
opt(2) fails with the error ENOPROTOOPT). SO_RCVLOWAT is
changeable only since Linux 2.4. The select(2) and poll(2) sys‐
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.
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
>
More information about the svn-src-head
mailing list