On Thu, 9 Feb 2006, Bulat Ziganshin wrote:
Thursday, February 09, 2006, 8:58:27 PM, you wrote: DC> "Slow" devices like pipes, sockets etc. get along fine with Handles DC> or whatever buffered I/O - as long as you have only one going at a time. DC> Multiple input sources - like, say you want to read a process' output DC> (unit 1) and diagnostic output (unit 2) separately, and either one has DC> the potential to fill up the pipe and block while you're waiting for DC> input on the other pipe - buffers at least complicate the dispatching DC> mechanics you need for this, if not make it impossible.
are you tried LineBuffering and NoBuffering? seem that it is developed exactly for this case (plus for terminals)
That's part of the idea, it helps keep the data out of buffers where select or whatever can't see it. But then you need functions with semantics that really support unbuffered I/O. When select tells you that the device is readable, you don't know that there is one full line, or how many bytes there are, so hGetLine doesn't apply here, nor would the Haskell equivalent of fread(3) if there were one. The only thing left is hGetChar - one char, then select, then another. (And multi-byte chars cause us to worry about this.) Since POSIX read(2) already supports exactly the functions you need for unbuffered I/O, it's simpler, easier and more efficient to leave the whole business right there at the file descriptor level. I'm sure you can make a non-buffering buffer layer work on top of the file descriptor, but what makes it worth the trouble? Donn Cave, donn@drizzle.com