CODEWITHSUNDEEP
clinuxshared-memorycode-cleanup
Orwellian Mentat
Orwellian Mentat

Reputation: 419

Behaviour of shm_unlink

I have the following code snippet :

fd_mem = shm_open(MEM_NAME , O_RDWR | O_CREAT | O_EXCL , 0600);

//Why do we use unlink before having mmaped ? 
shm_unlink ( MEM_NAME );

ftruncate (fd_mem , mem_size)
    
plateau = (char*) mmap(NULL , mem_size , PROT_READ | PROT_WRITE , MAP_SHARED , fd_mem , 0);

My question is: why do we use "unlink" before having mapped the file into the virtual memory of the process? I'm confused as to how shm_unlink() works in that regard. I would think it deletes the file making fd_mem unusable but it doesn't.

Upvotes: 0

Views: 1072

Answers (3)

John Bollinger
John Bollinger

Reputation: 180161

I'm confused as to how shm_unlink works in that regard, I would think it deletes the file rendering fd_mem unusable but it doesn't.

shm_unlink() removes the name of the shared memory segment. The segment itself persists as long as any process has it open, but after it is unlinked, processes can no longer open it. Even so, new processes forked from one that holds the shared memory segment inherit that, and one process can copy a file descriptor to another via a UNIX-domain socket, so being unlinked does not inherently limit which or how many processes can access the segment.

This is exactly analogous to the situation with regular files and unlink(). Successfully unlinking a file name removes that name from its directory, but the file itself is not removed as long as any process has it open.

Among the reasons to do this sort of thing are

  • to ensure that resources are cleaned up, whenever and however a process terminates. Named shared-memory segments persist as long as either they remain linked or a process holds them open. By unlinking a segment immediately after creating and opening it, a process helps ensure that it will not live longer than wanted, even if that process crashes.

  • to avoid unwanted access. Named shared memory segments can be opened by any process with sufficient privilege. Unlinking a shared memory segment helps control that. It especially helps avoid unwanted shared usage by multiple copies of the same program.

Note also that it is possible to create anonymous shared memory segments, which are never linked to a name in the first place. This is much as if a named segment were created, opened, and immediately unlinked, but it leaves no window in which another process can unwantedly open the segment by name.

Upvotes: 4

Rachid K.
Rachid K.

Reputation: 5211

Opening a file or a shared memory segment increments a reference counter on the underlying "kernel object". The deletion operation, deletes the name of the object but does not decrement the reference counter. As long the reference counter is bigger than 0, the object is not destroyed.

The deletion of the object after opening it, is for the automatic cleanup when the process terminates voluntarily (exit) or unvoluntarily (receipt of a signal) : the termination triggers a "close" operation which decrements the reference counter. When the latter drops to 0, the object disappears because the deletion operation completes as well.

Without this tricks, an process may terminate without doing any cleanup and consequently leaves "garbage" entries in the file system.

Upvotes: 1

Orwellian Mentat
Orwellian Mentat

Reputation: 419

Ok, what happens is that a file is only deleted once there are no more references towards said file, this includes open file descriptors, and since we have fd_mem, shm_unlink will remove the link in /dev/shm/MEM_NAME but the file will not be deleted until the fd_mem has been closed.

Upvotes: 1

Related Questions