apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: Local sockets
Date Thu, 23 May 2002 04:10:14 GMT
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 <aaron@clove.org>
> Message-ID: <20020111115006.K1529@clove.org>
> (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?


View raw message