Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!cory.Berkeley.EDU!fadden
From: fadden@cory.Berkeley.EDU (Andy McFadden)
Newsgroups: comp.sys.apple2
Subject: Re: pipes (implementation thereof)
Summary: slow
Message-ID: <22934@pasteur.Berkeley.EDU>
Date: 12 Mar 90 00:08:13 GMT
References: <6673@hydra.gatech.EDU> <1990Mar5.234421.396@world.std.com> <2218@tellab5.tellabs.com> <14398@reed.UUCP>
Sender: news@pasteur.Berkeley.EDU
Reply-To: fadden@cory.Berkeley.EDU.UUCP (Andy McFadden)
Organization: University of California, Berkeley
Lines: 35

In article <14398@reed.UUCP> reeder@reed.UUCP (Doug Reeder) writes:
>
>    IMHO, the best way to implement pipes is as follows: start the last
>program, and let it run along until it requests a character from the
>standard input from the OS.  The OS then starts up the next to last program,
>and lets it run untill it sends a character to standard output (by making an
[snip]
>lack vertical blanking interrpts).  The disadavantage is that you have to
>make a context shift for every character, unless you have multi-character
>reads and writes, which would be an excellent thing to have anyway.  You
>ought to be able to make syscalls like the ProDOS READ and WRITE and NEWLINE
>anyway.

There's an easy way around this, called buffer hysteresis.

If a reader outpaces a writer, then a buffer will never get full.  If a writer
outpaces a reader, then the buffer will always be full.  This means that we
will be performing needless context switches to processes which can't do
anything.

An easy thing way to deal with this is to wait until the buffer is full, and
then leave the writer sleeping until it is only half full (the reverse
condition leaves the reader sleeping from the time the buffer is empty to
the time it is half full).

The biggest problem is handling situations where a writer sends a few bytes
and then stops.  The buffer must be periodically flushed because of this.
A more insidious problem involves a circular pipe, but that is rather
uncommon.

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

-- 
fadden@cory.berkeley.edu (Andy McFadden)
...!ucbvax!cory!fadden