apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karsten Paige Huneycutt <...@duke.edu>
Subject RE: Local sockets
Date Fri, 02 Jan 1970 01:03:29 GMT

Hello --

I _could_ use named pipes, in theory, to do a portable
many-client-to-one-daemon solution.  The AGONIZING complexity comes in,
though, when you think about three simultaneous clients, all sending in
data in nine separate bursts and expecting six separate bursts from the
server daemon -- trying to assure that the EXACT client that sent in the
request gets the response to that EXACT request is... non trivial.  I 
have
been trying to think about doing funky things with locking and
removing/recreating the named pipe/FIFO, but that's extremely 
non-portable
as well.  Having only one client able to send/receive data from the 
daemon
would make the daemon's threadedness not at all useful, so I'm not 
willing
to go that route.

One thing I did think of was having a unidirectional named pipe that the
client uses to send the key of the shared memory segment to the server.
I could open the pipe and then write-lock it, write the length followed 
by
the data, then release the lock, no interleaving woes, and the meat of 
the
data passing would be in shared memory, so the threadedness would still 
be
quite useful.

If I did it that way, with shared memory, I would need cross-process
condition variables (to signal the client process when the server daemon
is done messing with the memory segment) and mutexes.  Do APR's
apr_proc_mutex_t support being used by non-child processes, as long as
they're passed via shared memory, a la POSIX thread's
PTHREAD_PROCESS_SHARED?  How about apr_thread_cond_t (which I
doubt since they only accept apr_thread_mutex_t, not 
apr_proc_mutex_t...)?

However, any implementation with shared memory or apr_spipe_t would ruin
the ability for a single data type (apr_socket_t) to be used in terms of
data passing, assuming I want to keep the network extensibility I have in
mind.  I guess I'm perfectly willing to write that sort of wrapper
function around the read/write/connect/disconnect -- but if i do that, I
may as well go ahead and write the wrapper function around apr_socket_t 
vs
local domain sockets, and just ignore the MUCH more complex
shared-memory+named-pipe solution.  That's what I'll end up doing, I
think, if you guys don't decide to add AF_LOCAL returning APR_ENOTIMPL
sometimes into the socket code, which will give me an #ifdef/#endif, 
which
I wanted to avoid for platform-specific things, and which would ruin the
beauty of being able to always read and write from the same data type.
But I can do it.

KH


On Thu, 23 May 2002, Ryan Bloom wrote:

> Why aren't named pipes usable in your application?  APR already has a
> named pipe implementation, which would solve this problem.

--
Karsten Huneycutt               A casual stroll through a lunatic
kph@duke.edu                    asylum shows that faith does not
http://www.duke.edu/~kph        prove anything  --Nietzsche


Mime
View raw message