apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyler MacDonald <ty...@yi.org>
Subject Re: RFC: graceful handling of abandoned shared memory
Date Wed, 26 Apr 2006 16:04:27 GMT
Joe Orton <jorton@redhat.com> wrote:
> On Wed, Apr 26, 2006 at 08:34:55AM -0700, Tyler MacDonald wrote:
> > Joe Orton <jorton@redhat.com> wrote:
> > > The patch also introduces a new problem: what if a previous process had 
> > > created a shm segment with that key and a different size?  You can't 
> > > carry on regardless in that case.
> > 
> > 	Hmm. True. It may be better to destroy and re-create it.
> apr_shm_remove()! :)
> > > I don't understand from your previous mail why you can't use 
> > > apr_shm_remove() before creating the shm segment at startup.
> > 
> > 	I only want the segment to be removed if nobody else is using it.
> > Will apr_shm_remove() fail if the segment is still in use?
> No, that can't be done for e.g. named mmap.  apr_shm_remove() semantics 
> should be consistent across all Unix platforms - I think all these 
> things should be true:
> 1) any persistent (i.e. filesystem) references to the shm segment will 
> be removed;
> 2) the memory allocated for the shm segment itself will be released when
> the last process using it either exits, calls _destroy on the 
> shm object, or the object's pool cleanup runs;
> 3) it will no longer be possible for any process to attach to the 
> deleted shm segment;
> 4) it will be possible to create a new (and distinct) shm segment given 
> the same name as the deleted shm segment.

	Soooooo..... would you recommend using, say, a lockfile mechanism to
prevent one set of processes from stepping on the shared memory toes of
another? I'm assuming if the master process took out an APR_FLOCK_SHARED on
the path to the shared memory, that file lock would die with the process...?
I'm guessing other processes could still write to the shared memory under
the SysV model (since the file is just a pointer to a memory address), what
about under mmap?


View raw message