Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!genrad!decvax!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: PIPE:... should it buffer at all?  Of course it should
Message-ID: <8709021850.AA22653@cory.Berkeley.EDU>
Date: Wed, 2-Sep-87 14:50:08 EDT
Article-I.D.: cory.8709021850.AA22653
Posted: Wed Sep  2 14:50:08 1987
Date-Received: Sat, 5-Sep-87 06:51:34 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 26

>Which means that's not how pipes work. What I suggested was not having any
>buffer in the pipe structure at all, but instead using the buffer provided
>by the writer in its message. That way if the program used an 8K buffer, it
>would automatically transfer 8K. If the program used 256 byte buffers, it
>would transfer 256 bytes. The writer would always wait for the reader to read
>the entire buffer, and data would be transferred straight from the writer
>to the reader. This would save memory and time, at the cost of making the
>writer wait on small writes. It's certainly worth looking into, anyway.
>-- 
>-- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter
>--                  U   <--- not a copyrighted cartoon :->

	No, you *WANT* to buffer data.  The whole idea is to increase CPU
throughput.  For instance, lets say you are running an uncompress from a 
disk file.  uncompress takes a lot of CPU, but when it gets the next block
from disk it must wait.

	But, if you pipe a copy into the uncompress, the copy will do all
the waiting and the uncompress will run full speed IF the pipe buffers data.
An even better example is going the other way... compressing a file TO disk.

	So in general, if the source can jam data out faster then the 
destination can read it, you want buffered pipes so the destination can run
full speed.

				-Matt