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

[Leo Razoumov <lrazoumov@qualcomm.com>]

>>>>> "MF" == Matthew Flatt <mflatt@cs.utah.edu> writes:
    MF> 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).

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

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

GREAT!!!! When is 102 released??

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

    MF> Operating systems aren't as good at this as you might think :), at
    MF> least not in my opinion. 

But they are getting better:-) 

    MF> While getting [non-]blocking output to work
    MF> right in MzScheme, I had to learn about all the ways that Unix's
    MF> select() and the non-blocking flags are broken, particularly when TTYs
    MF> are involved. 

For such simple things as dup2 it is not necessary.

    MF> Probably dup2 really would work well in Unix for many purposes, but
    MF> then there are arbitrary ports (not to mention Windows and MacOS) to
    MF> worry about. 

dup2 is a POSIX.1 function and therefore should be supported by WinNT, Win2000
as well. 

    MF> I speculate that a `redirect-port!' that worked precisely
    MF> like dup2 on file descriptions would be hard to define for other kinds
    MF> of ports; we would implement the general case like the code I sent out,
    MF> but unless that code is exposed by the definition of `redirect-port!',
    MF> its definition would have to tackle messy issues related to thread and
    MF> resource control with custodians, etc.

I agree with the points you are making. It is probably *NOT* a good idea to make
redirect-port! a part of the MzScheme *CORE* language. But I still beleive it is
worthwhile to have a Unix (POSIX) extension library which provides most handy
pieces of Unix API. 

Also there is another problem with "copy-stream" implementation of redirect-port:
with a read/write approach it is all but impossible to synchronize FROM and TO
stream positions. What happens if my subprocess "myprog" uses 'lseek' and
repositions its output file position. This new position will not be propagated
into the redirected MzScheme port without "myprog" to explicitly send this
information to MzScheme process over IPC (what a mess).  On the other hand
file descriptors duplicated with dup2 share file positions and such a problem
does not happen (dup2 is also MT-safe).

I am trying to promote Scheme (in particular MzScheme) here as a universal
scripting/extension language and to drop Perl (Tk/Tcl) all together. My
colleagues are keeping asking me "nasty" practical questions like: how do I do
this-and-that in Scheme what I can do in Perl in the middle of a night with my
eyes closed?  What should I answer?

-- Leo

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+  Leonid Razoumov,               +  E-mail: lrazoumov@qualcomm.com   +
+  Qualcomm Inc.,                 +  http://www.qualcomm.com          +
+  5775 Morehouse Drive,          +                                   +
+  San Diego, CA 92121-1714,      +  VOICE:  +1-858/651-5163          +
+        USA                      +    FAX:  +1-858/658-2113          +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++