Re: [Q] HOWTO redirect a i/o-port in Unix??

[Matthew Flatt <mflatt@cs.utah.edu>]

Quoting Leo Razoumov:
> Your solution would not work (in general) if you are redirecting more
> than one port at once because it may cause a dead-lock situation.
> [...]
> The dead-lock symptoms are:
> 1). MzScheme will block in the myprog's stderr read/write loop when there is
>     nothing to read from the stderr.
> 2). "myprog" will block at the same time if it fills up the output buffer
>     of its stdout pipe. This pipe is not being consumed at the MzScheme end
>     because MzScheme is blocked by item 1).

I don't think your example quite captures a problem. In MzScheme, when
one thread is blocked on a read, other threads can proceed. In the
above example, when the stderr-reading thread is blocked, the
stdout-reading thread can proceed.

However, in 101 and previous versions, a MzScheme thread blocked on a
*write* would actually block all MzScheme threads. This has been fixed
in 102, so that pipelines can be implemented reliably. (The build
process for MzScheme2k uses a pipeline.)

> However, a much simplier solution would be to provide a primitive
> function like (redirect-port! FROM TO) which essentially does dup2
> and let Operating System handle all the gory details of I/O
> operations.

Operating systems aren't as good at this as you might think :), at
least not in my opinion. While getting [non-]blocking output to work
right in MzScheme, I had to learn about all the ways that Unix's
select() and the non-blocking flags are broken, particularly when TTYs
are involved. 

Probably dup2 really would work well in Unix for many purposes, but
then there are arbitrary ports (not to mention Windows and MacOS) to
worry about. I speculate that a `redirect-port!' that worked precisely
like dup2 on file descriptions would be hard to define for other kinds
of ports; we would implement the general case like the code I sent out,
but unless that code is exposed by the definition of `redirect-port!',
its definition would have to tackle messy issues related to thread and
resource control with custodians, etc.

Maybe something like `redirect-port!' will be possible in the future,
but we'll have to think about it even more than we already have...

Matthew