Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!cornell!uw-beaver!mit-eddie!killer!pollux!ti-csl!tifsie!kent
From: kent@tifsie.UUCP (Russell Kent)
Newsgroups: comp.os.minix
Subject: Re: Pipes and other oddities...
Message-ID: <575@tifsie.UUCP>
Date: 24 Jan 89 00:47:50 GMT
References: <449@duteca4.UUCP>
Organization: TI Process Automation Center, Dallas Texas
Lines: 81

Just thought I'd chime in, and add some interesting new info too --

in article <449@duteca4.UUCP>, knop@duteca (P. Knoppers) says:
>> 1.  My instructor insists that under *nix and/or MINIX, a single pipe can
>> flow data in both directions between processes... ie., a pipe can be opened
>> for both read and write.  Please, someone back me up on this - I swear a 
>> pipe is a one-way flow - opened for read-only at one end and write-only
>> at the other.  Please flame one of us, gently.
> You're both right.... and wrong

Actually, I believe the student is only right.  It's the instructor who is
both right and wrong.  Of course, the student is guilty of omission:
what constitutes an "end" to a pipe?

A pipe is in fact a one-way flow.  It is open for reading at "one end"
and writing at "the other [end]."  The trick is that an "end"
can consist of more than one file descriptor.  So if two processes each
have a pair of file descriptors, one on the reading "end" and one on the
writing "end", then data may flow between the processes.  However, since
pipes are essentially character-oriented, nothing guarantees any sort of
sense to the delivery of byte read with respect to bytes written.  Example,
if process #1 writes "Hello", and process #2 writes "Bonjour", and then
both processes read from their respective read "end" descriptors, it would
be perfectly legal for them to read say "HeBnjlloo" and "our".
(Henry Spencer's reply may explain this better.)

> 
> Comments:
> - The shell cannot create a circularly connected set of processes. There
>   is simply no way to specify such things on the command line.
> Peter Knoppers - knop@duteca.UUCP

Actually Peter, if your "*nix" supports named pipes, then you can do some
interesting things like:

    mknod loopback p
    tweedle < loopback | diagnose > loopback

Theoretically, this should work.  Unfortunately, reality does not always
conform to theory.

(The following analysis is 20% fact and 80% hunch)
It seems that the shell hangs when opening "loopback" for reading (this
is on SunOS), waiting for a writing end of the named pipe to exist.  This
is probably to prevent the EOF from appearing on tweedle's stdin before
the writing has had a chance to come into existence, and only happens
when starting.  The unfortunate bi-product is that the shell is about to
create the writing end of the named pipe (diagnose's stdout).  Therefore,
instant self-deadlock.  The solution?  Don't cause the shell to open
"loopback" for reading:

    cat loopback | tweedle | diagnose > loopback

Interesting, no?

(For those of you I have baffled, I appologize.  There really is
no straightforward way to describe this without assuming the reader
has a fairly thorough understanding of how pipes work.  If you
really want to understand, start by reading the info on pipe(2)
in your local Unix machine.  If you still don't understand, then
find a copy of Maurice Bach's _Design_of_the_Unix_Operating_System_
(Prentice-Hall) and read the section on pipes and on name-to-inode
mapping.)

Author's Note:
  We (Texas Instruments) really use this construct.  We have a piece
of manufacturing equipment that comes with diagnostic software that is
flexible, but not too smart.  What we did was write a program which
reads the output of the diagnostics, analyzes it, and then "types" further
commands onto the diagnostic's stdin, much as a warm-bodied engineer
would do.
------------------------------------------------------------------
Russell Kent                  UUCP:         convex!smu!tifsie!kent
Texas Instruments                    sun!texsun!ti-csl!tifsie!kent 
PO Box 655012  M/S 3635           ut-sally!im4u!ti-csl!tifsie!kent
Dallas, TX 75265              Voice: (214) 995-3501   TI-MSG: RAK9
-- 
Russell Kent                  UUCP:         convex!smu!tifsie!kent
Texas Instruments                    sun!texsun!ti-csl!tifsie!kent 
PO Box 655012  M/S 3635           ut-sally!im4u!ti-csl!tifsie!kent
Dallas, TX 75265              Voice: (214) 995-3501   TI-MSG: RAK9