lkml.org 
[lkml]   [2008]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Honoring SO_RCVLOWAT in proto_ops.poll methods
On Sat, Sep 20, 2008 at 03:21:40PM -0700, David Miller wrote:
> From: lkml@pengaru.com
> Date: Sat, 20 Sep 2008 16:42:29 -0500
>
> > I have a need for select/poll/epoll_wait to block on sockets which have
> > unread data sitting in the receive buffer with a quantity less than
> > specified via setsockopt() w/SO_RCVLOWAT, not less than one like the
> > current implementation.
>
> If BSD never provided this behavior, such a change is likely
> to break applications.

I did a quick look through FreeBSD source on fxr and found this macro:
http://fxr.watson.org/fxr/source/sys/socketvar.h#L197

Which is used by the generic socket poll here:
http://fxr.watson.org/fxr/source/kern/uipc_socket.c#L2731

You can look throughout that listing and so_rcv.sb_lowat is always what
is compared against for determining rcv buf readability.

You might also want to look at the socket(7) man page which implies that
what Linux currently does is exceptional & incorrect:

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 initialised to 1. SO_SNDLOWAT is not
changeable on Linux (setsockopt fails with the error ENO-
PROTOOPT). SO_RCVLOWAT is changeable only since Linux
2.4. The select(2) and poll(2) system calls currently do
not respect the SO_RCVLOWAT setting on Linux, and mark a
socket readable when even a single byte of data is avail-
able. A subsequent read from the socket will block until
SO_RCVLOWAT bytes are available.


Regards,
Vito Caputo


\
 
 \ /
  Last update: 2008-09-21 01:03    [W:0.043 / U:1.960 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site