[Haskell-cafe] Emulating bash pipe/ process lib

[Donn Cave]

On Fri, 10 Feb 2006, Bulat Ziganshin wrote:
...
> 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

Don't know - I see that Simon M followed up with an explanation that
I think confirms my impression that LineBuffering is indistinguishable
from BlockBuffering, for input.  I assume it's only there for the sake
of output, where it does make a difference.

Only NoBuffering is interoperable with select.

> 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?

It returns whatever available data, as long as it's more than 0 bytes
and less than the caller-supplied limit.  This is the only read operation
that works with select (including char-at-a-time, as a special case
where the caller-supplied limit is 1.)

> 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.

It won't!  I mean, we can use it the same way as the ordinary Handle in
the original example, but we know in principle, if you call vGetLine,
it may block regardless of whether select reports input data, because
select can't tell you whether there's a full line of input.

So you don't have anything to worry about here - this is not your problem.
I only wanted to point out that for select-based I/O event multiplexing,
we will continue to need file descriptors and system level POSIX I/O,
and that the need for this can occur in such ordinary, mundane applications
as reading stdout and stderr in parallel.

	Donn Cave, donn at drizzle.com