🚀 go-pugleaf

In  <1990Oct19.044319.4851@engin.umich.edu>,
Ralph Seguin (gilgalad@caen.engin.umich.edu) asks:
> Does anybody know whether or not Amiga OS 2.0 will support "true pipes",
> ie pipes ala UNIX?  I am considering writing a true pipe handler, but
> I don't want to waste my time if C= is going to do it for me 8-).
>
[I think this topic crops up afresh every month or so, but never mind...]
OK -- what exactly ARE the criteria for "true" pipes?  Or at least, which
do you find necessary?   I've always felt that the form of unix pipes was
really just a fallout from that system's unique "fork". It isn't
necessarily the most flexible for other systems like the Amiga.

I suspect that your main requirement is that they be unnamed.  This is
a natural mechanism under unix, where the shell (or other initiator) is
the direct parent of both processes that will share the pipe, so it can
acquire both ends at once. and pass one to each of its children.  The
kernel call to do this is not interruptible, so arranging to get a couple
of matching descriptors back is no problem.

Amiga DOS is NOT synchronous like the unix kernel, though, and the
standard FindInput and FindOutput calls will only pick up one end at a
time -- and there's no way of matching ends without a name...
It would of course be possible, I guess, to add a new Packet type that
would set up TWO handles at once, but is it worth it?

Giving names to pipes has advantages in an more anarchic (well.. less
hierarchically strict, anyhow (:-)) OS like the Amiga's, in that two
otherwise totally unconnected processes can use them to communicate.  You
get problems too, of course, the two main ones being the burden of having
to think of -- and type! -- names, and conflicts between names.  The latter
is most vexing when you want to run multiple copies of a script, for
instance.

Both of these are real problems only if you're working from a shell.
The first is trivial if you're invoking processes from a program of your
own, and the second isn't much harder: you simply keep going through
some straightforward name sequence until you find an unused one.  (This
is easy in ARexx, too; I do it this way regularly.)

Both of these are real problems only if you're working from a shell.
The first is trivial if you're invoking processes from a program of your
own, and the second isn't much harder: you simply keep going through
some straightforward name sequence until you find an unused one.  (This
is easy in ARexx, too; I do it this way regularly.)  Mostly we need to
make the Shell suitably smart -- AND design a suitable syntax. (Avoid "|"
please!)

If, as at least one person (Gregory Kritsch in <ggk.657249739@tirith.UUCP>)
has desired, you want to write a POpen function -- or even a pipe(fildes)
call -- I don't see why you can't do it the same way. You don't really need
an unnamed-pipe device.  (I see that someone has done just this, from a
posting just encountered.)


On the OTHER hand....  The 1.3 PIPE: is not the device we want to have
to live with.  Not only is it buggy (I've had it refuse to accept perfectly
good names) but it lacks one other characteristic that I consider vital
to a true pipe: it is NOT "transparent"!  In other words you can't read
anything from it until either the buffer (4096 bytes I think) has been
filled or the input end is closed.  This makes interactive applications
impossible.

And this is why I wrote the IP-device -- now available on Fish Disk #374.
[aa...HA!!  Now his ulterior motive is exposed... ]  This is a pipe with a
couple of twists in it. (:-))  It IS transparent -- a packet passed to it is
immediately available for reading -- but in addition you can have more than
one input active (a "funnel") and you can keep it open beyond the closing
of its inputs (so for example you could pipe sporadic logging outputs to a
compression program or something).  Also you can open a "pipe-console" that
will let you get in and out of a Shell via pipes.

Okay, so you still have to name your pipes, but I'm doing things with
the IP-device that weren't possible before, like having ARexx ship lines
off to another process (with no ARexx port) for massaging -- and getting
them back!  One caution: most C programs probably use buffered output
anyway, which is efficient, but defeats us if we want line by line output;
fortunately the program in this case was mine (Mat), so I quickly wrote in
fflush calls after every newline.  (The version of Mat also on #374 does
NOT flush every line. Sorry!)


                                        -- Pete --