Re: Honoring SO_RCVLOWAT in proto_ops.poll methods

[lkml@pengaru.com]

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