Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!agate!violet.berkeley.edu!pete From: pete@violet.berkeley.edu (Pete Goodeve) Newsgroups: comp.sys.amiga.tech Subject: Re: PIPEs Summary: unnamed pipes needed? Message-ID: <1990Nov3.073201.8227@agate.berkeley.edu> Date: 3 Nov 90 07:32:01 GMT References: <53407.657565922@atronx.UUCP> Sender: usenet@agate.berkeley.edu (USENET Administrator) Organization: University of California, Berkeley Lines: 86 In <53407.657565922@atronx.UUCP>, Russell McOrmond (rwm@atronx.UUCP) writes: > In a message posted on 2 Nov 90 09:15:42 GMT, > pete@violet.berkeley.edu (Pete Goodeve) wrote: > PG>time -- and there's no way of matching ends without a name... > > Hmmm - Here's what I end up doing. I end up Opening the Pipe Twice to get two > filehandles - I then use one of them in my program, and pass the other one to > a program that I'm running. I DO get these descriptors at the same time. Well, no. You're actually making two calls to the OS with the same name, NOT making a single call that returns two matching file descriptors -- which is what I meant. > Here's WHY you wish them to be un-named this way you KNOW that the names are > unique: I sorta thought that was what I was saying...(:-)) A little more diffusely than you though, I'll admit. > I now do some convaluted task+timer thing to try to make sure I have > a unique name. With the number of times I use it, it's inevidable that the same > name gets used twice. > > So what might I end up having to do? A Pipe-Name-Server that's protected by a > semaphore? All because I don't have Un-named pipes?? I'm sorry, but I don't really see the difficulty. As long as your device objects if you try to do more than one open simultaneously with the same name, all you do is keep trying opens with slightly different names until one succeeds. The moment you do succeed, you've got an exclusive, and any other process going through the same business will pass over than one and find a unique one of its own. If you have a reasonable way of hashing up a name, you shouldn't have to make more than a couple of probes before you get in. To be more concrete, here's some [really] pseudocode for a "pipe(fildes)" function: Make an initial stab at a name, perhaps using the middle bits of the current process address as a basis -- getting 'P!4283' say. Do an fopen call on your pipe device -- probably at the read end -- with that name. If the call fails, add something (modulo 10000 or whatever) to the numeric part of the name, and go back to the previous step. [You could simply add 1, if the name space is sparse enough, or you could choose some different increment for each process.] When an open succeeds, do another fopen -- for write -- to the same name. Return both read and write file handles in the 'fildes' structure supplied. And that's it. > > Names are fine when it's a USER that's doing it - BOTH types of pipes are required > at different times. Neithor type of pipe is perfect for ALL applications. > But when it comes down to it, all pipes, unix-type too, are ""named"" -- even if only by the hex address of the control structure! The only important point is whether the user has to WORRY about it. Seems to me all you need to remove that worry is some scheme like the above. > > PG>make the Shell suitably smart -- AND design a suitable syntax. (Avoid "|" > PG>please!) > > What's wrong with that notation? Just that the "|" character is significant in AmigaDos pattern matching. I'm not quite sure how you'd be certain of distinguishing its use there from a pipe request. > If you don't like that, what do YOU suggest. Well... er... ahh... (:-)) To brutally honest, I haven't really given much thought to the topic at all (which is why I didn't actually MAKE any suggestion!). Maybe after I've thought a while, I will. Seems like a suitable topic for net discussion, anyhow. -- Pete --