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 [EMAIL PROTECTED] asylum shows that faith does not http://www.duke.edu/~kph prove anything --Nietzsche
