[Haskell-cafe] Re: standard poll/select interface

[Simon Marlow]

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 
OS-thread blocking.

Cheers,
	Simon