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). 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
