Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!hao!ames!sdcsvax!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: MCC pipes
Message-ID: <8706120539.AA16159@cory.Berkeley.EDU>
Date: Fri, 12-Jun-87 01:39:57 EDT
Article-I.D.: cory.8706120539.AA16159
Posted: Fri Jun 12 01:39:57 1987
Date-Received: Sat, 20-Jun-87 13:40:09 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 63

>You create a named pipe with a mknod call. As a special case anyone can do
>this. The pipe is therefore just another special file. You can open it
>and write to it just like a file. You can open it and read from it similarly.
>Unlike PIPE: pipes, a reader doesn't hang on opening... it hangs on a read.
>Similarly a writer doesn't hang: it can just write its bytes and get out of
>there without waiting for a reader to show up. You also don't hang on close
>waiting for your coconspiritor to finish. Otherwise it's pretty much the same.
>
>It would be nice if the MCC PIPE: would handle more packets. For example,
>Examine and ExNext.

	You are, fortunetly, wrong. I wrote PIPE:, and it neither blocks
on Open() nor blocks on Write().  In fact, I certainly hope MCC pipes have
a provision for non-infinite buffer sizes, or they are useless to me.  Perhaps
you are refering to a very early version of my PIPE:?

	Specifically, you can specify the buffer size for PIPE: pipes easily
enough:  'pipe:name/b#'.  If you want an infinite buffer size (writer NEVER
blocks), then 'pipe:name/n' suffices.  Without any options, the pipe uses a
4K buffer.

	For non infinite buffer sizes, my PIPE: allows the writer to write
until the buffer is full, then waits for it to drain down to half before 
allowing the writer to write again.  If the reader can keep up with the
writer, then the writer never blocks.  The reason for this is obvious: reduce
the number of task switches while still attaining 100% CPU utilization.

	Now you may ask, 'why not just make it use infinite buffer sizes
as a default'??  That's an easy question to answer.  By example I will 
describe how I construct my VD0: disk from floppy power up:

	given A 600K file on the floppy containing the COMPRESSED, ARCHIVED 
	VD0: (As in backup, not arc), I setup two pipes between three 
	programs which will run concurrently.
	
	(A) A Copy from the 600K file to the first PIPE: specifying a 
	relatively large, but not infinite, buffer size (I use a 128K buffer)

	(B) A DECOMPRESS from the first PIPE: to a second PIPE: using
	an infinite buffer size.

	(C) A de-archive (restore) from the second PIPE:.  restore takes the
	decompressed archive file and reconstructs the entire VD0:.


	Now, I don't want to use an infinite buffer size for the first PIPE:
	because the Copy is *much* faster than decompress, and would basically
	get most of the 600K file in RAM: before decompress got through the
	first 50K.  600K + memory that decompress uses + a partially restored
	VD0: is quite a bit more than the measily 2.5Meg I've got.  I can use
	an infinite buffer size for the second PIPE: because Restore can
	read data much faster than the decompressor can decompress it.  

	The net result is 100% CPU utilization.  What you see is 128K bytes
	read from the floppy, about a 10 second wait while uncompress reduces
	the pipe buffer to around 64K, then a 64K byte read from the floppy,
	another 5 seconds, another 64K byte read, etc... until all 600K
	has gone through.  Meanwhile, uncompress has enjoyed *never* having
	to block when reading the compressed file from the first PIPE: In fact,
	that first PIPE: rarely gets smaller than 64K until Copy is finished
	reading the disk file.

					-Matt