apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mladen Turk" <mt...@mappingsoft.com>
Subject Re: [PROPOSAL] apr_shm_t, a new shared memory API to replace old
Date Tue, 08 Jan 2002 19:37:24 GMT

----- Original Message -----
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: "Mladen Turk" <mturk@mappingsoft.com>; "'Aaron Bannert'"
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
> You miss the point.  We don't know how the user has chosen to lock.
> 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.]
> it's created, apr_shm has NO NEED for a lock, whatsoever.  The users of
> contents quite possibly do.  But here, we have no idea of what their
> entails.  Is it crossproc?  crossthread?  Only the coder knows, we can't
> 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.


View raw message