Date: Tue, 14 Jan 2003 10:34:42 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Gary Thorpe <gathorpe79@yahoo.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: getsysfd() patch #1 (Re: Virtual memory question) Message-ID: <200301141834.h0EIYgD4081141@apollo.backplane.com> References: <20030114142450.57943.qmail@web41215.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:A quick note: I don't think its a "race condition" necessarily, but it
:is purposefully designed that way: processes have to remove shared
:memory segments themselves and they may die before doing so. If your
:program exits normally after creating a SysV shared memory segment
:without removing it, it will stay around (I suppose because it is
:globally accessable by processes having the right key). Perhaps a sort
:of garbage collection scheme for it would be useful (i.e. if reference
:count reaches zero [all the mapping processes have exited], delete it),
:but then suppose you want data to persists in it? Same for SysV
:semaphores and message boxes I think.
The most common sysv shared memory operation is to create a
private shared memory segment for a program while it is running.
You normally do this by creating the segment, mapping it, and
then removing the segment. Deleting the segment does not removing
the mapping, it simply causes the kernel to physically remove the
segment once the last reference to it has gone away.
There is a race during this create/map/delete process. If the
process is killed after the create but before it manages to delete
the mapping, the mapping remains in the shm tables (ipcs -a).
A far better solution to this common scenario is to have a
filesystem rendezvous, like a FIFO (see mkfifo), where the kernel
simply blows everything away after the last reference has disappeared,
or to have a descriptor-based rendezvous which has the same effect
when the descriptor is closed (and all mappings have gone away)
for the last time.
:The third solution is anonymous mappings via mmap(), but I only think
:that can be shared by parent and children after fork(). Is there a way
:to share this with non-related (in terms of fork() hierarchy)
:processes?
No. Well, there might be a trick that could be played with exec(),
but basically no. Even depending on fork() is not reliable. FreeBSD
supports shared memory on fork(), but it isn't guarenteed across all
available unix architectures (i.e. on some UNIX systems you can't
have MAP_SHARED memory across a fork and the space becomes
copy-on-write).
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301141834.h0EIYgD4081141>