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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/