SO_RCVLOWAT option to socket()

SO_RCVLOWAT option to socket()

[Rob Sanders]

Hey y'all,
    Can anyone point me to a resource for why SO_RCVLOWAT is hardcoded 
to 1 in linux?
If you are using select or poll with timeouts it would be less costly 
to have the kernel tell you
when all of the data you reqested (via SO_RCVLOWAT) is ready to be read 
instead of putting
your select/poll followed by read inside a loop to handle any partial 
data deliveries.  I've got some
code that uses SO_RCVLOWAT running under OS X, and it should run under 
Tru64, but doesn't
do what I want under Linux.  The socket man page indicates that 
SO_RCVLOWAT is hardcoded to 1.
   Please respond to me offline if possible, I don't have the time or 
resources right now to handle the
full subscription to this mailing list.  Thank you.

						Rob

						rarob
						at
						comcast
						dot
						net

Re: SO_RCVLOWAT option to socket()

[Alan Cox]

On Gwe, 2004-12-10 at 04:06, Rob Sanders wrote:
> Hey y'all,
>     Can anyone point me to a resource for why SO_RCVLOWAT is hardcoded 
> to 1 in linux?

The 1003.1g drafts require it is supported.

> If you are using select or poll with timeouts it would be less costly 
> to have the kernel tell you
> when all of the data you reqested (via SO_RCVLOWAT) is ready to be read 

But is the cost of all those special case checks and all the handling
for
it such as select computing if enough tcp packets together accumulated
worth
the cost on every app not using LOWAT for the microscopic gain given
that
essentially nobody uses it.

Alan