[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apr-dev
Subject:    Re: RFC: graceful handling of abandoned shared memory
From:       Joe Orton <jorton () redhat ! com>
Date:       2006-04-27 11:55:52
Message-ID: 20060427115552.GA32742 () redhat ! com
[Download RAW message or body]

On Wed, Apr 26, 2006 at 09:04:27AM -0700, Tyler MacDonald wrote:
> Joe Orton <jorton@redhat.com> wrote:
...
> > 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:
...
> > 4) it will be possible to create a new (and distinct) shm segment given 
> > the same name as the deleted shm segment.

Actually, (4) cannot be strictly guaranteed for SysV shm since there is 
no guarantee in POSIX that different keys will returned by ftok for 
files with different inode numbers: but for practical purposes it is 
probably OK to rely on this being true.

> 	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...?

Note that you cannot rely on a file being created at the path passed to 
apr_shm_create(); e.g. for POSIX shm_open() it probably won't.

> 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?

In all cases it should be true that even once the shm object is 
destroyed using apr_shm_remove() any processes which already had the shm 
object mapped will still be able to use it, if that's what you meant.

Your code to _attach then _destroy an existing shm segment if _create 
fails seems reasonable; I don't think APR attempts to give any guarantee 
about the error code given in this case but EEXIST probably covers most 
cases.

Regards,

joe
[prev in list] [next in list] [prev in thread] [next in thread]