Utilities 3 (Disk 38) (Mar 1987) : c / pipedevice /


Name Size Date Type
misc.c 1790 1987-01-03 Text [Original]
mountlist 119 1987-01-03 Text [Original]
pipe.c 13238 1987-01-03 Text [Original]
pipe.device 3244 1987-01-03
POSTER 4544 1987-01-03 Text [Original]


File: 1999.comp-sys-amiga
Path: ...!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: PIPE: device (1.2 only)	*******
Date: 6 Feb 87 20:12:17 GMT
Date-Received: 8 Feb 87 04:41:36 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 608

	Here's a PIPE device.  I would like to thank Phillip Lindsay
for providing the skeleton device driver which I used as a base.  This
will ONLY WORK WITH 1.2!!.  Example (run all at once):

CLI window 1:	copy hugefile pipe:a
CLI window 2:	copy pipe:a pipe:b
CLI window 3:	copy pipe:b pipe:c
CLI window 4:	copy pipe:c pipe:d
CLI window 5:	copy pipe:d pipe:e
CLI window 6:	wordcount pipe:e		(or something similar)

	You can, of course, use any rendezvous name you wish.  The device
uses a 4K internal buffer per name, but is optimized to take advantage of
the situation in which there is a pending read and a pending write. In this
case it copies direct rather than go through its internal buffer.  This is
a true pipe, and thus the source and destination processes must be distinct
(i.e. not the same process) so as to prevent lockout situations.  The buffer
is transparent in that data written, no matter how little, is immediately
available to be read by the other process.

	You must place PIPE.DEVICE in 'DEVS:'.  Append the MOUNTLIST file to
DEVS:MOUNTLIST (or just put it there if you do not have a DEVS:MOUNTLIST),
and then do a 'MOUNT PIPE:' in your startup script.

	The source is provided also.  Remember, since this is a device, you
do NOT link with any startup module.  I have done a couple of other tests
and have found that you get a huge efficiency increase when piping an IO
bound program through a CPU bound program or vise versa.  This is totally
public domain except for MISC.C, which is (C) to Phillip (but redistributable).
The binary itself is totally public domain.


	I hope to have my shell use the PIPE: device in it's next release,
but this will require huge modifications to the shell so don't expect the
next release anytime soon. 

Apart from that, the PIPE: device can be useful when you have, say, two
application programs and want to transfer huge amounts of data from one 
(write) to the other (read) without using a temporary file in RAM: or on
disk.  Assuming the application does not attempt a Seek(), you simply
specify 'PIPE:name' and it looks like an ordinary file to the application.

For those terminal programs which do not use asyncronous writes, you can
fix the jerkyness in CAPTURE by capturing to a pipe, and having another
CLI Copy command running from the pipe to a file.

					Have fun and report any bugs to me,

File: 2001.comp-sys-amiga
Path: ...!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Other PIPE examples
Date: 7 Feb 87 00:34:28 GMT
Date-Received: 8 Feb 87 04:53:53 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 38

Lets say you want to look at a hunk disassembly of AMIGA.LIB . The
ascii dump that HUNKS gives for that is well over 200K.  Assuming you have
limited memory and can't have the file in RAM and edit it at the same
time, and assuming you don't want to wait for it to dump to disk:

	CLI 1>	hunks >pipe:xx amiga.lib
	CLI 2>	med pipe:xx

	where HUNKS is the hunk-dumping program, and MED is an editor.  MED
	was barely able to fit the entire file in my 512K Amiga.

Another cute thing I did just for laughs was to Capture to a pipe:xx file
from my terminal program, and have a

	CLI 1>	wordcount pipe:xx

	running from the CLI.  When I finish the session and the terminal
	program closes the Capture, the wordcount gets an EOI and tells me
	how many chars/words/lines came over the modem in that session.

Any program which writes out small buffer sizes to disk can be made more 
efficient by specifying a pipe as the output file, and then running a 
copy concurrently (which uses large buffer sizes):

	CLI 1>	hunks >pipe:a amiga.lib 
	CLI 2>	fgrep >pipe:b LVO pipe:a 
	CLI 3>	copy pipe:b file

I haven't tried this yet, but it should be possible to specify a pipe as
a compiler's temporary file, then have all passes of the compiler, including
the assembler or code generator in memory and running at the same time.  
Needless to say this presumes having a lot of memory in your Amiga... say,
2 Megs?