[Haskell-cafe] Re: standard poll/select interface
simonmarhaskell at gmail.com
Tue Feb 28 04:25:16 EST 2006
Marcin 'Qrczak' Kowalczyk wrote:
> Simon Marlow <simonmarhaskell at gmail.com> 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
More information about the Haskell-Cafe