Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site leopard.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!leopard!perry
From: perry@leopard.UUCP (Perry S. Kivolowitz)
Newsgroups: net.micro.amiga
Subject: Re: Yes, we...do pipes. (Propose Proposal)
Message-ID: <158@leopard.UUCP>
Date: Wed, 26-Feb-86 09:15:27 EST
Article-I.D.: leopard.158
Posted: Wed Feb 26 09:15:27 1986
Date-Received: Fri, 28-Feb-86 07:45:08 EST
References: <730@amiga.amiga.UUCP>
Organization: Rest Home For Aged Bit Twiddlers
Lines: 31

> Guess what.  You can use "pipes" on the Amiga to pipe the output of one
> process to the input of another.  This requires:
> 
> 	no C code
> 	no programming knowlege
> 	the enclosed execute file.
> 

For a kludge the best thing that  can  be said about a cli script approach to
simulating pipes is, that it's a  kludge and a pretty poor one at that. Pipes
are *REALLY* trivial data structures and could very easily be added in a full
blown (including named pipes) fashion.  It  might even be possible for a full
pipe implementation to be done with out o.s. changes. 

One possibility is to modify  the C  run  time environment (including reading
and writing) to use a circular list of  message headers where UNIX (tm) would
use a circular buffer. Two essential properties of pipes would be preserved:

	(1)	That i/o to and from  pipes  be identicle to the programmer
		as other i/o.

	(2)	That concurrent operation of every stage of the pipeline is
		possible limited only by the  nature of the task to be per-
		formed (and run-a-way prevention).

If the changes are not made on on the kernel level, than one problem would be
standardization since  anybody  could  define their own pipe method. My ideas
on this subject are pretty well formed: If the net or C-A would like, I could
post these as the basis of an ad hoc pipe standard proposal.

Perry S. Kivolowitz