Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <023b01c19877$f4896620$93c0b0d0@v505>
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: "Mladen Turk" <mturk@mappingsoft.com>,
	"'Aaron Bannert'" <aaron@clove.org>
Cc: <dev@apr.apache.org>
References: <20020108002539.D1529@clove.org>
 <000701c19824$9bcc59f0$5f00000a@armada> <20020108100402.G1529@clove.org>
 <006c01c19873$c1d11290$5f00000a@armada>
Subject: Re: [PROPOSAL] apr_shm_t, a new shared memory API to replace old
Date: Tue, 8 Jan 2002 13:08:57 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: "Mladen Turk" <mturk@mappingsoft.com>
Sent: Tuesday, January 08, 2002 12:38 PM


> > > Ok, I'll try.
> > > When creating shared memory segment you have two choices, either using
> > > file or anonymous mem segment. Well, the problem with using anonymous
> > > mem segment is that you still need the name to identify that segment if
> > > you want to use it across non-child processes.
> > No, anonymous memory is not for use across non-child processes. If
> > you want to use memory across unrelated processes you have to make
> > it name-based.
> 
> Yes, that's my point. Anonymous shmem can be cross-process (on WIN32) if you
> give it the name, then instead using regular file it will be backed up by
> the system paging file. So, you need to name it.

Yes... that corresponds to 'keyed' shared mem.  We will be backing by a file
for now, and anon will be backed by a key.  Anon will be unnamed, so you will
have to dup the handle to pass it.  That meta-API needs to be determined, not
only for shm, but for _ALL_ our handles.

Let's leave that aspect alone for a few hours :)  I'm overloaded with too
many API bits right at this moment.  I'm much more worried about having a
scoreboard that isn't stuck in place, and can be reopened in the child at
a different address.


> > > The lock I've mentioned is generated from that name, but that could be
> > > leaved to the caller to cope with, but it would be much elegant to add
> > > two extra calls to shmem, like apr_shmem_lock/unlock. That way you could
> > > easily use the apr_rmm alloc scheme.
> > >
> > > Other important usage of locks would be to signal the caller if he's the
> > > initial owner of that shmem object.
> >
> > I'm not quite sure how locks came into this discussion, since they are
> > purposefully excluded from the apr_shm_t API. It is up to the caller to
> > do their own locking if they wish to synchronize access to a shared memory
> > segment. Perhaps it will make more sense to continue this discussion in
> > the context of apr_rmm.
> 
> 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.

Bill