On Thu, May 23, 2002 at 12:01:45AM -0400, Karsten Paige Huneycutt wrote: > According to the API posted in > > Date: Fri, 11 Jan 2002 11:50:07 -0800 > From: Aaron Bannert <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > > (which is the last mention I can find in the dev@apr.apache.org archives), > the apr_spipe_t looks _great_ for parent-child IPC, but is in no way meant > to serve the same function that local sockets serve. Instead, it seems to > replace/augment pipe(...), not socket(AF_LOCAL, SOCK_STREAM, 0). There is > no way I can see to get one of the apr_spipe_t's returned from > apr_spipe_create accessible in another process, save for a fork/exec. As > I mentioned, the application I'm re-writing does NOT communicate with > children, but rather, with entirely unrelated processes. > > If apr_spipe_t has been extended to include this sort of functionality, > could the API be posted again?
Since this is an obvious requirement for spipe to work on Windows where there is no concept of process inheritance, I would agree that the original spipe API will have to be extended. I'm open to suggestions at this point. In a way, the API we write for this will probably be extended to concepts like shared memory and cross-process mutexes, which have always been a bit ackward for writing fully portable code. How will Windows rendezvous with the other process? Perhaps by some unique name or a file in the filesystem? What needs to be passed between the processes in order to establish such a connection? -aaron
