[Haskell-cafe] Re: standard poll/select interface
simonmarhaskell at gmail.com
Tue Feb 21 08:15:48 EST 2006
John Meacham wrote:
> On Fri, Feb 10, 2006 at 12:26:30PM +0000, Simon Marlow wrote:
>>in fact, I think this should be the basic API, since you can implement
>>readFD in terms of it. (readNonBlockingFD always reads at least one
>>byte, blocking until some data is available). This is used to partially
>>fill an input buffer with the available data, for example.
> this is the behavior of standard file descriptors. not non-blocking
> ones. We should definitly not guarentee reads fill an input buffer
> fully at least for the lowest level calls, that is the job for the
> layers on top of it.
You're right - I was slightly confused there. O_NONBLOCK isn't
necessary to implement readNonBlockingFD.
>>One problem here is that in order to implement readNonBlockingFD on Unix
>>you have to put the FD into O_NONBLOCK mode, which due to misdesign of
>>the Unix API affects other users of the same file descriptor, including
>>other programs. GHC suffers from this problem.
> non blocking ones will return immediatly if no data is available rather
> than make sure they return at least one byte.
> In any case, the correct solution in the circumstances is to provide a
> select/poll/epoll/devpoll interface. It is nicer than setting
> NON_BLOCKING and more efficient. This is largely orthogonal to the
> Streams design though.
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 agree that a generic select/poll interface would be nice. If it was
in terms of Handles though, that's not useful for implementing the I/O
library. If it was in terms of FDs, that's not portable - we'd need a
separate one for Windows. How would you design it?
More information about the Haskell-Cafe