Messages in this thread | | | From | Andrew Tridgell <> | Subject | Re: shared memory deallocation | Date | Mon, 27 Apr 1998 15:10:17 +1000 |
| |
> 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
| |