On Fri, 24 Feb 2006, Marcin 'Qrczak' Kowalczyk wrote:
> Simon Marlow <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
