perry@leopard.UUCP (Perry S. Kivolowitz) (02/26/86)
> Guess what. You can use "pipes" on the Amiga to pipe the output of one > process to the input of another. This requires: > > no C code > no programming knowlege > the enclosed execute file. > For a kludge the best thing that can be said about a cli script approach to simulating pipes is, that it's a kludge and a pretty poor one at that. Pipes are *REALLY* trivial data structures and could very easily be added in a full blown (including named pipes) fashion. It might even be possible for a full pipe implementation to be done with out o.s. changes. One possibility is to modify the C run time environment (including reading and writing) to use a circular list of message headers where UNIX (tm) would use a circular buffer. Two essential properties of pipes would be preserved: (1) That i/o to and from pipes be identicle to the programmer as other i/o. (2) That concurrent operation of every stage of the pipeline is possible limited only by the nature of the task to be per- formed (and run-a-way prevention). If the changes are not made on on the kernel level, than one problem would be standardization since anybody could define their own pipe method. My ideas on this subject are pretty well formed: If the net or C-A would like, I could post these as the basis of an ad hoc pipe standard proposal. Perry S. Kivolowitz
bees@infoswx.UUCP (03/04/86)
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-0570james@uw-june (James Synge) (03/07/86)
<eat me, please!> AmigaDos has devices SER:, PAR:, etc which can be treated very much like parts of the filing system. At the exec level you can create new devices using the routines AddDevice, etc. I would like to know how to create a new AmigaDos device. What I intend to do is write a routine like the Unix routine pipe(fd[2]) which returns two file descriptors, one can be written to, the other can be read. Somehow AmigaDos needs to know what to do with these fds and this is not well documented (I could find no such info). Is there anybody who has the sample device driver given in the Rom Kernel manual, Vol 2, appendix G? It would be a great help to have those posted to the net (or sent direct). Many thanks to Matt Dillon of UCB for posting his C shell. If I am able to create the above pipe() I will incorporate it into csh and post the changes to the net. - James M. Synge University of Washington, Seattle UUCP: ...!uw-beaver!uw-june!james VOICE: (206)543-0308