Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!tellab5!toth
From: toth@tellab5.tellabs.com (Joseph G. Toth Jr.)
Newsgroups: comp.sys.apple2
Subject: Re: pipes (implementation thereof)
Summary: mea culpa, mea culpa, ...  Well, only a little sorry ;^}
Message-ID: <2291@tellab5.tellabs.com>
Date: 24 Mar 90 12:57:30 GMT
References: <2284@tellab5.tellabs.com>
Organization: Tellabs, Inc. Lisle, IL
Lines: 45

In article <2284@tellab5.tellabs.com>, toth@tellab5.tellabs.com (Joseph G. Toth Jr.) writes:
> > 
> >     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.

After getting home, I thought about what I wrote here..

While what I stated true in the cases of output dumped to a file; output
dumped to a printer would begin sooner than by waiting till all processes
before the printer are completer by passing intermediate files as RAMdisk
files.

I am assuming that the last process that received output from its
predecessor initiates the backward search for output by its request for
more input.

Practicality must still be issues (usable memory, processor speed,
managability, implementation effort, and time).

The feature would be very nice; but how valuable is it; how much time should
be spent in developing the fastest feature vs. how much time does it really
save for the user (and, are those savings really meaningful).
Most users have slow DMP devices for hardcopy (if they had high speed printer,
they would probably also have a more powerful computer), so saving a couple
minutes on a 20 minute printing job (a few seconds on a 3 minute print, etc.)
would seem to make the effort impractical.

I feel that the feature is nice, but, considering the user market and 
target for implementation; IMHO the simplest solution is best.

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