[Haskell-cafe] Emulating bash pipe/ process lib

Bulat Ziganshin bulatz at HotPOP.com
Fri Feb 10 02:12:14 EST 2006


Hello Donn,

Friday, February 10, 2006, 12:47:42 AM, 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)

DC> That's part of the idea, it helps keep the data out of buffers where
DC> select or whatever can't see it.

DC> But then you need functions with semantics that really support unbuffered
DC> I/O.  When select tells you that the device is readable, you don't know
DC> that there is one full line, or how many bytes there are, so hGetLine
DC> doesn't apply here, nor would the Haskell equivalent of fread(3) if there
DC> were one.  The only thing left is hGetChar - one char, then select, then
DC> another.  (And multi-byte chars cause us to worry about this.)

when i think how to implementat LineBuffering, i decided that it is
the only possible way - read byte a time and see for a '\n'. i don't
know how System.IO implemented but i think that it should do the same

DC> Since POSIX read(2) already supports exactly the functions you need for
DC> unbuffered I/O, it's simpler, easier and more efficient to leave the whole
DC> business right there at the file descriptor level.

can you please describe that read(2) does that is better than reading
char-at-a-time?

DC> I'm sure you can make
DC> a non-buffering buffer layer work on top of the file descriptor, but what
DC> makes it worth the trouble?

if you don't have I/O library that implements what you need, it is
indeed simpler to use lower I/O directly. if you have I/O library that
does that you need, it is easier to write:

(hIn, hOut) <- createUnixPipe
vPutStrLn hOut "hello"
s <- vGetLine hIn

i'm writing such lib now, so i'm interested to know what i need to
do so that it will work ok.


-- 
Best regards,
 Bulat                            mailto:bulatz at HotPOP.com





More information about the Haskell-Cafe mailing list