Path: utzoo!attcan!uunet!samsung!xylogics!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: comp.sys.apple2
Subject: Re: pipes (implementation thereof)
Message-ID: <1990Mar24.165558.3866@world.std.com>
Date: 24 Mar 90 16:55:58 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> <14461@reed.UUCP>
Organization: Saber Software
Lines: 32

reeder@reed.UUCP (Doug Reeder) 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.

Typically this is all the way to the first process.

>This technique gets
>information to the end as quickly as possible, where you often have a human
>waiting around to see what comes out.

So make the buffer size smaller and get the same results with
"traditional" techniques.

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

You interrupt processes a LOT, once for every task switch.  It's not a
preemptive interrupt, so you don't need a timer, but it's an interrupt
nonetheless.  Nonpreemptive switching is pretty common.

>Furthermore, you needn't
>worry about processes which take a long time to generate their next output,

There ain't no such thing as a free lunch.  That program is going to
take a long time with your scheme too.

jim frost
saber software
jimf@saber.com