Path: utzoo!attcan!uunet!tellab5!toth
From: toth@tellab5.tellabs.com (Joseph G. Toth Jr.)
Newsgroups: comp.sys.apple2
Subject: Re: pipes (implementation thereof)
Summary: The easiest solution just might be the best!!!
	 The Hardware just seems to get in the way...
Message-ID: <2284@tellab5.tellabs.com>
Date: 23 Mar 90 14:50:43 GMT
Organization: Tellabs, Inc. Lisle, IL
Lines: 80

First of all - in order to provide multi-tasking (which is refered to in
   the articles), the OS/Shell would have to work using interrupts.  Most
   owners of Apples (][, ][+ //e - The //c includes a mouse interface which
   can generate timing interrupts) don't have clocks or mouse controllers
   to provide the timing interrupts required to provide multi-tasking.

Second - in order to make any gains provided by task switching, all I/O to
   disk, etc. would require new hardware to allow interrupting I/O control
   and/or DMA.  Since there has been no uniformity to restrictions regarding
   the use of interrupts in the past (DMA requires use of interrupt lines)
   almost all current I/O device drivers (hardware and software) would have
   to be scrapped.

References: <6673@hydra.gatech.EDU> <1990Mar5.234421.396@world.std.com> <14461@reed.UUCP>

In article <14461@reed.UUCP>, reeder@reed.UUCP (Doug Reeder) writes:
> 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.

In the ProDOS environment, and with all currently available hardware, the
switching of tasks and the OS/Shell determining which level has output
for the next program will not get the output to the user faster...
All that overhead in the OS/Shell is simply that; added OVERHEAD.
It would actually take longer than the simple method stated next.

>     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.

The point of pipes is to get an output from a sequence of operations..

On a single user system the amount of code executed by the series of
programs remains constant.  Therefore, any added overhead that is
performed in selecting which task executes simply because some output
is availabe is simply that: ADDED OVERHEAD.
And that overhead will ADD to the time it takes to complete the desired
series of operations used to obtain an output, not decrease it.
Simply using a RAMdisk for intermediate storage of information would
make piping data at least tolerable.

>     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.

On this last point; I Agree, whole-heartedly.

> -- 
> Doug Reeder                         USENET: ...!tektronix!reed!reeder


-- 
------------------------------------------------+---------------------
Maybe I shouldn't have done it, sarcasm is so   | Joseph G. Toth Jr.
seldom understood.  Don't FLAME on me, please.  | uunet!tellab5!toth