
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). Select/poll/epoll are designed to work primarily with non-blocking I/O.
Ah yes, you're right. It's important for us to guarantee that calling read() can't block, so even if we select() first there's a race condition in that someone else can call read() before the current thread.
In my implementation of my language pthreads are optionally used in the way very similar to your paper "Extending the Haskell Foreign Function Interface with Concurrency". This means that I have a choice of using blocking or non-blocking I/O for a given descriptor, both work similarly, but blocking I/O takes up an OS thread. Each file has a blocking flag kept in its data.
That's an interesting idea, and neatly solves the problem of making stdin/stdout/stderr non-blocking, but at the expense of some heavyweight OS-thread blocking. Cheers, Simon