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