Re: Deleting a shared memory object created with dhm_open?

From: Tony 'Nicoya' Mantler (nicoya_at_ubb.ca)
Date: 12/21/04 

Date: Tue, 21 Dec 2004 17:17:51 GMT

In article <1103632690.858280.325980@f14g2000cwb.googlegroups.com>,
 clusardi2k@aol.com wrote:

: Hello,
:
: I have a library routine (below) that opens the same SGI/Linux
: shared memory object on each invocation by separate programs.
:
: Should I ever delete the shared memory object? Does it matter if I
: delete it? What's the best way to delete it (unlink or rm)? When should
: I delete it?
:
: The only problem that I can see occurring is deleting something
: that other programs are using!
:
: (I'm desperate, so is there a way to find out if other programs are
: using the shared memory object.)
:
: The reason I'm asking about this deletion is one month ago I had to
: reboot my system. I did this because the "IPCS" command told me that
: there were shared memory objects accumulating on the system.
:
: I really don't know why the extra shared memory objects were
: there. I just rebooted and everything appeared to be fine. In the
: future, should I just watch IPCS and worry about it only when it shows
: up again?
:
: I rebooted my system recently for other reasons, and I haven't
: been monitoring IPCS.

Technically an application can't directly delete something on a unix system,
only the kernel can.

It helps to think of a file as an object with multiple pointers. When you create
a file on disk you get an on-disk pointer, and when you hard link the file you
get another on-disk pointer. When you call open() or dup() you get an in-memory
pointer, and close() deletes it.

Once all these pointers have been deleted (every fd close()d and every on-disk
link unlink()ed) the kernel will see that the reference count is now zero, and
will remove the file from existence.

Ditto with shared memory objects.

You don't say exactly what your desired behaviour is, so here's a few examples
of perfectly valid file manipulations:

1: open/creat() a file
2: unlink() the file
- The file can now no longer be found in the filesystem namespace, but still
exists
3: read/write() to the file
4: dup() the file descriptor
5: close() all file descriptors
- The file is now deleted by the kernel

1: open/creat() a file in process A
2: open() file in process B
3: unlink() file
- The file can now no longer be found in the filesystem namespace, but still
exists
4: read/write() to the file from either process, each will see the changes in
the data
5: close() the file descriptor in both apps
- The file is now deleted by the kernel

1: open/creat() a file in process A
2: unlink() the file in process A
3: open/creat() the same file name in process B
4: unlink() the file in process B
- Two different files now exist, but cannot be found in the filesystem namespace.
5: read/write() to the files from either process, each will not see each other's
data
6: close() all the file descriptors
- Both files are now deleted by the kernel

and, of course, there's the more normal procedure:

1: open/creat() a file
2: read/write() to the file
3: close() the fd
4: unlink() the file
- The file is now deleted by the kernel

I hope this helps your understanding a bit.

Cheers - Tony 'Nicoya' Mantler :) 

-- 
Tony 'Nicoya' Mantler -- Master of Code-fu -- nicoya@ubb.ca
--  http://nicoya.feline.pp.se/  --  http://www.ubb.ca/  --