Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!shelby!agate!violet.berkeley.edu!pete From: pete@violet.berkeley.edu (Pete Goodeve) Newsgroups: comp.sys.amiga.tech Subject: Re: PIPEs Keywords: PIPE, IP-Device Message-ID: <1990Nov2.091542.25505@agate.berkeley.edu> Date: 2 Nov 90 09:15:42 GMT References: <1990Oct19.044319.4851@engin.umich.edu> Sender: usenet@agate.berkeley.edu (USENET Administrator) Distribution: na Organization: University of California, Berkeley Lines: 83 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 ) 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 --