lkml.org 
[lkml]   [1998]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: shared memory deallocation
Date
> Umm, yeah. That's what it's supposed to do. Shared memory is supposed to
> be persistant, so that you can access it from other processes even if no
> processes have been using it in the meantime.

One thing that many people may not be aware of (it seems to surprise
many people when I mention it) is that IPC shared memory has reference
counters. This means you can use IPC_RMID on a shared memory ID after
attaching to the memory and still access the pointer. When the process
exits the shared memory allocation goes away. Shared memory allocated
in this way is inherited by child processes but can't be attached to
from other processes. (this is analogous to closing a file after using
mmap() and still being able to access the memory).

So, if what you are doing is setting up shared memory before a fork()
then remember to RMID it and you won't have to have any annoying
scripts that parse the output of ipcs to free up memory.

Example of how to do this (and how to use 3 other mechanisms to obtain
shared memory that work on various OSes) is available from
ftp://samba.anu.edu.au/pub/tridge/misc/shm_sample.c. I wrote that
after the Nth person asked me about shared memory ...

some people may also be interested in
ftp://samba.anu.edu.au/pub/tridge/misc/semspeed.c which shows an
enormous difference in the speed of SysV semaphores vs fcntl for
locking on various OSes.

Cheers, Andrew

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.043 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site