Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site mcrware.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!stolaf!umn-cs!isucs1!mcrware!kim
From: kim@mcrware.UUCP (Kim Kempf)
Newsgroups: net.micro.68k
Subject: Re: Re: Holy Holistic, Batman!  (OS-9 and the art of being holistic)
Message-ID: <139@mcrware.UUCP>
Date: Mon, 7-Oct-85 11:07:09 EDT
Article-I.D.: mcrware.139
Posted: Mon Oct  7 11:07:09 1985
Date-Received: Sat, 12-Oct-85 15:29:28 EDT
References: <576@sftig.UUCP> <1001@bnl44.UUCP> <11467@rochester.UUCP> <6014@utzoo.UUCP>
Organization: Microware Systems Corp., Des Moines, IA
Lines: 77

> > .... Opening a named pipe is done through open()...
> 
> That's how it works in Unix too.
> 
> > ... you read and write from it with no special features like sockets...
> 
> Same comment.  Sockets are a Berkleyism, and arguably a botch.
> 
Ok, some of you UNIX-sheltered programmers need a lesson on advanced OS-9
programming topics.  OS-9 pipes can be "named" much like disk directory
files:

	open("/pipe/msg_socket", ...)

Any process can open this pipe by name.  The process need not have a common
ancestor with the creating process creating the pipe.  Another feature of
the named pipes is that the pipe file manager makes the opened named pipes
look like disk directories.  For example, the command:

	copy *.c -w=/pipe/files

copies all files (*.c) into the pipe named "files".  A subsequent:

	dir /pipe/files

will display the names of the pseudo-files waiting in the pipe.  As the files
are read, the pseudo files are removed from the pipe.  The files are read in
FIFO order from the pipe.

The named pipes being described are much easier for the programmer to use.
One need not set up I/O path for forking the pipe-reader, not to mention
the overhead involved is performing same.  This facility has many practical
applications that can ease a programmer's houskeeping duties.


> > ...  Forks are done by giving the name of your function and the
> > parameters to a OS-9 system call, and the routine is forked into a child
> > process -- no having to place both parent and child code into a big "if"
> > statement...
> 
> This is actually a nice idea; hold on five minutes while I write a C
> function to do it under Unix...  (Yes, there is a defect in that said
> function probably ought to be a standard feature rather than a local hack.)
> 
The UNIX-style fork REQUIRES memory management to clone the data and stack
area for the new process.  If this were done without memory management,
pointers would change causing the forked process to crash.

> 
> General comments:  There are definitely a lot of places where Unix could
> be cleaned up if you started from scratch.  Of course, this would break
> compatibility with every other Unix on Earth, a serious defect considering
> that portability is one of Unix's strong points.

Not entirely. The proliferation of UNIX source code has resulted in numerous
hacks that compromise portability.  Just try porting between BSD 4.2 and
System V.

> things that look strange do make sense if you look at them closely and
> understand what they are used for.  (For example, the fork/exec split looks
> odd until you try to figure out how to implement things like i/o redirection
> and shell pipes without it; the ability to modify the environment after
> the fork but before the exec is important.)

Must not be too hard to do.  OS-9 does it quite well.  And much faster!

> Before attempting to "fix Unix's mistakes", it is wise to understand
> which of them aren't mistakes.

...but kludges in disguise!

----------------
Kim Kempf, Microware Systems Corporation

  {{cornell,decvax,ihnp4,sdcsvax,tektronix}!uw-beaver}\
 {allegra,gatech!sb1,hplabs!lbl-csam,decwrl!sun,sunup} >!fluke!mcrware!kim
{ssc-vax,hplsla,wavetek,physio,cae780,tikal,telematic}/