Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tektronix!reed!reeder
From: reeder@reed.UUCP (Doug Reeder)
Newsgroups: comp.sys.apple2
Subject: Re: pipes (implementation thereof)
Message-ID: <14461@reed.UUCP>
Date: 20 Mar 90 04:47:34 GMT
References: <6673@hydra.gatech.EDU> <1990Mar5.234421.396@world.std.com> <2218@tellab5.tellabs.com> <14398@reed.UUCP> <1990Mar13.022324.19402@world.std.com>
Reply-To: reeder@reed.UUCP (Doug Reeder)
Organization: Institute of Knowledge, Jinx
Lines: 41

In article <1990Mar13.022324.19402@world.std.com> madd@world.std.com (jim frost) writes:
_reeder@reed.UUCP (Doug Reeder) writes:
__    IMHO, the best way to implement pipes is as follows: 
_
_This is a poorer technique as it degrades immediately into the
_traditional buffer-output-until-buffer-full-or-done technique, and
_additionally requires all processes to be active at one time for at
_least some of the processing.

    Apaarantly it was not clear that when the first process outputs to the
second, the OS immediately switches to the second process, and when the
second sends output, the OS switches to the third, so you only need to go
back through the chain untill you get some output.  This technique gets
information to the end as quickly as possible, where you often have a human
waiting around to see what comes out.  Also, if a process does not read
until end-of-file, the information it doesn't use is never generated.
    It does require all processes be active, but if you can't have all of
them active, you're almost better off running the first all the way through,
sending its output to a file, then running the second, and so on.


_You've gained nothing, since your technique degraded immediately to
_the traditional.  
    On the contrary, you gain something quite important: you never need to
interrupt a process, which is quite important on the IIe and other machines
which don't have regularly scheduled interrupts.  Furthermore, you needn't
worry about processes which take a long time to generate their next output,
as all final output that could possible be generated already has been, i.e.
all the processes after the time-consuming one cannot proceed without the
information the time-consuming one is generating.
    Thus you can write a ProDOS shell that does real pipes, if you can get
all the appropriate commands in memory at once.  (You'll need relocatable
external commands.)  Pipes and few programs that run in the background, such
as print spoolers and file transfer would provide most of the features,
IMHO, that people want from an Apple II Unix.

-- 
Doug Reeder                                   USENET: ...!tektronix!reed!reeder
from ARPA: tektronix!reed!reeder@berkeley.EDU BITNET: reeder@reed.BITNET
the Little Mermaid on materialism:
I just don't see how a world that makes such wonderful things ... could be bad!