Re: select() doesn't respect SO_RCVLOWAT ?

[Willy Tarreau <willy@w.ods.org>]

On Thu, Mar 10, 2005 at 04:58:51PM -0500, Felix Matathias wrote:
> 
> I am running a 2.4.21-9.0.3.ELsmp #1 kernel and I can setsockopt and 
> getsockopt correctly the SO_RCVLOWAT option, but select() seems to mark a 
> socket readable even if a single byte is ready to be read. Then, a read() 
> blocks until the specified number of bytes in SO_RCVLOWAT makes it to the 
> socket buffer.

as discussed in a previous thread, if you use select(), you should also
use non-blocking sockets. There are cases where select() can wake you up
without anything to read, eg if there is a packet waiting with a wrong
checksum.

> This is the exact opposite behaviour of what I yould have 
> expected/desired. Our application receives data at many Khz rate and we 
> want to avoid reading the socket until a predetermined amount of data is 
> sent, to avoid partial reads. SO_RCVLOWAT seemed to be a nice way to 
> implement that.

I too came across this problem a long time ago and concluded that LOWAT
was not really usable on Linux. But in the end, this is not really a big
deal, because as long as your application doesn't eat all CPU, it does
not change anything performance-wise, and when it becomes to eat a lot
of CPU, the latency will increase, letting more data come in when you
do one read.

> An earlier message by Alan Cox was a bit cryptic:
> 
> "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."
> 
> Does this mean that select() in Linux will wake up no matter what 
> SO_RCVLOWAT is set to ?

Yes.

Regards,
Willy