Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site csd1.UUCP
Path: utzoo!linus!decvax!harpo!floyd!cmcl2!csd1!condict
From: condict@csd1.UUCP (Michael Condict)
Newsgroups: net.unix-wizards
Subject: Re: Unix philosophy
Message-ID: <117@csd1.UUCP>
Date: Sun, 18-Sep-83 16:40:07 EDT
Article-I.D.: csd1.117
Posted: Sun Sep 18 16:40:07 1983
Date-Received: Mon, 19-Sep-83 00:54:18 EDT
References: <1075@utcsstat.UUCP>
Organization: New York University
Lines: 50

I'm no expert on the requirements and applications of interprocess
communication (IPC) but I do know that any reasonable definition of what
constitutes an IPC mechanism would include the now widely acclaimed Unix
pipeline.  Therefore it depresses, even saddens, me to hear so many people
talk about ways to do IPC in Unix without any discussion of pipelines (except
to immediately dismiss them as too weak).  If there are any remaining adherents
of the original Unix philosophy of Parsimony and Elegance in Design out there
besides me, please make your voices heard!  Surely there must be a reasonably
simple way to remove the heredity constraints on pipelines, so that arbitrary
processes can connect to and disconnect from one another, and an upward-
compatible way to add the necessary concurrent processing features to pipelines
(do we need more than a few things like mutually-exclusive read/write access,
flexible permission codes and the ability to find out the number of processes
that have a pipe open or the number of unread bytes sitting in a pipe?).

If we really cannot generalize the pipeline construct adequately, then let us
at least have the courage to throw it away, and replace it with your new-fangled
IPC system.  But please, please let us not allow Unix to grow fat and ugly,
but rather taller and more powerful.  No matter what gross iniquities are
done to it in the name of progress, Unix will be around to help or haunt us
for many years.  It has become the FORTRAN of operating systems with respect
to the number of different processors it runs on, the variety of tasks
to which it is applied and (because of the former two) its longevity.  We need
to be very careful that we do not let the analogy extend any further than this.


Michael Condict			...!cmcl2!csd1!condict
Courant Inst., New York U.

P.S.  Here's a concrete proposal (someone must have already thought of this).
Why not let pipelines have names that appear in the file system as a new kind
of directory entry in addition to files and directories.  Then they can
live and die independently of processes and any process that knows the name
of a pipeline and has the right permission can read or write to it.  This is
the VMS approach, with its mailbox devices, which are nothing more than a
generalized pipeline of the sort I'm proposing (actually it's less, because
the VMS designers forgot to make these mailboxes accessible at the command
level for connecting processes together easily, but that does not argue against
the utility of mailbox devices as an IPC).  Of course we would preserve the
current behavior of pipes with respect to shells creating them automatically
upon seeing "|" in a command; only the explanation of what goes on internally
would change.  Actually, this proposal simply amounts to having a new kind of
file, in which things are deleted as they are read and which is inherently
sequential (seek is not allowed).  Of course we would expect the kernel to go
out of its way to store most or all of this kind of file in main storage, for
efficient access.  As for the concurrent processing features, like mutual
exclusion, we can benefit from having these features available for pipes, files
and devices alike, so there is no particular reason to associate them only
with pipes.