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

[Simon Marlow]

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?

Cheers,
	Simon