----- Original Message -----
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: "Mladen Turk" <mturk@mappingsoft.com>; "'Aaron Bannert'"
<aaron@clove.org>
Cc: <dev@apr.apache.org>
Sent: Tuesday, January 08, 2002 8:08 PM
Subject: Re: [PROPOSAL] apr_shm_t, a new shared memory API to replace old


> > Perhaps it would, but only in the context of the alloc/free
synchronization.
>
> You miss the point.  We don't know how the user has chosen to lock.
apr_shm's
> will never need to lock [we presume the code is serialized, and the parent
> creates the shm/rmm before children begin to stick their fingers in in.]
Once
> it's created, apr_shm has NO NEED for a lock, whatsoever.  The users of
the
> contents quite possibly do.  But here, we have no idea of what their
locking
> entails.  Is it crossproc?  crossthread?  Only the coder knows, we can't
be
> any help here.  If we tried, we would end up forcing them to code into our
> paper bag.

The locking I was thinking of was in the pupose to determine the initial
owner status, in the case you have couple of services comunicating with each
other. So that lock (not the apr_proc_mutex_create but CreateMutex(NULL,
TRUE, somename)) will give that info and the coder could decide to cope with
that fact.

MT.