This is a discussion on shared memory not getting freed within the Linux Programming forums, part of the Platform Specific Boards category; Originally Posted by brewbuck That's pretty much verbatim what you said. show me where I said that. Originally Posted by ...
The kernel keeps its own copy of the shmid_ds strcuture associated with the shmid - so attachment counts are system-wide.
The reason I ask is because in SunOS/Solaris/AIX documentation, it explicitly states that children of fork() inherit existing attachments and the associated shm_nattach member of shmid_ds is incremented by 1 as a result of calling fork().
I don't know if this is the case on your system. If it were, then the following call order would be bad:
- parent-attach (++shm_nattach)
- fork (++shm_nattach)
- child-attach (++shm_nattach)
Since you say you're calling fork() fist, then this shouldn't be a problem.
Instead of a SHM segment with an identifier, you have a file in the filesystem. The identifier is the file path. Suppose you wanted to share a 10 megabyte segment between multiple processes. You create the segment by creating a file in the filesystem of size 10M. Call it /path/to/segment.
Then each process which wants to share that 10 megabyte space will open() the /path/to/segment file. Then, using the file descriptor returned, they would call mmap() to map that 10 megabyte space into their address space. At that point, the memory can be accessed just like a SHM segment. All the processes will see all changes to that memory.
The memory itself is cached on disk in the /path/to/segment file. This file will not be deleted by the operating system. So it "sticks around" like a SHM segment, but it sticks around on disk, not in memory, so it's nowhere near as much of a problem if nobody deletes it.
The performance of shared mmaps is identical to that of SHM segments.
You can read the man page for mmap() to figure out how to call it, and I'd be happy to answer questions about it.