
On Fri, 24 Feb 2006, Marcin 'Qrczak' Kowalczyk wrote:
Simon Marlow
writes: I think the reason we set O_NONBLOCK is so that we don't have to test with select() before reading, we can just call read(). If you don't use O_NONBLOCK, you need two system calls to read/write instead of one. This probably isn't a big deal, given that we're buffering anyway.
I've heard that for Linux sockets select/poll/epoll might say that data is available where it in fact is not (it may be triggered by socket activity which doesn't result in new data).
Only UDP, from anything I'm able to find out about this. Apparently a UDP packet may turn out to be invalid in some respect, to be discovered too late during the recvmsg system call. In a similar situation, the TCP layer would have already accounted for this by the time select sees anything. Likewise of course any local slow devices like a tty, pipe etc.
Select/poll/epoll are designed to work primarily with non-blocking I/O.
That's what the Linux kernel developers say, anyway, since it would be inconvenient for them to fix this, even though it apparently violates the POSIX specification. Donn Cave, donn@drizzle.com