Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site infoswx
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!convex!infoswx!bees
From: bees@infoswx.UUCP
Newsgroups: net.micro.amiga
Subject: Re: Yes, we...do pipes. (Propose Pr
Message-ID: <45100030@infoswx>
Date: Mon, 3-Mar-86 19:43:00 EST
Article-I.D.: infoswx.45100030
Posted: Mon Mar  3 19:43:00 1986
Date-Received: Fri, 7-Mar-86 04:16:35 EST
References: <158@leopard.UUCP>
Lines: 31
Nf-ID: #R:leopard.UUCP:158:infoswx:45100030:000:1386
Nf-From: infoswx.UUCP!bees    Mar  3 18:43:00 1986


My idea of a pipe implementation is similar to named pipes in System V,
at least in some ways.  What I envision is a new device driver.  Call
it PIPE: if you like.  Then you either modify CLI or write your own CLI
to recognize |'s.  The CLI runs all the commands asyncronously, with
either input or output attached to PIPE:.  PIPE: is implemented as a
simple 4K (or whatever you want) circular buffer, with blocking reads
and writes!

A couple of problems, though...

How do I implement a new driver and have anything recognize "PIPE:" ?

Something has to identify separate pipes.  Either the CLI, or the PIPE
device.  One possibility is that the CLI opens PIPE: for read and
write, and hands the same file to the output of the first proc and the
input of the second.  The pipe device would then have to distinguish
between separate opens.  Hmmm... I don't like that implementation.  I
guess there needs to be an open for write and an open for read, but
then how do we connect the two?

How about the CLI always doing an open("PIPE:n", O_WRONLY|O_CREAT|O_EXCL)
where n is a "unique" number (it can retry if not unique), for the first
proc.  Then it does an open("PIPE:n", O_RDONLY), for the second proc.
And the final close() removes the pipe "file".

What is your idea?  It should be simple...  shouldn't it?

Ray Davis
Teknekron Infoswitch, Richardson, TX
infoswx!bees, (214)644-0570