Messages in this thread | | | From | Bruno Haible <> | Date | Thu, 16 Mar 2000 16:47:31 +0100 (MET) | Subject | Re: SHM and programs unable to attach to shm segments |
| |
The next thing that breaks is XFree86 4.0. X now uses shared memory to transport the font glyph metrics from the server to the local clients; the server creates the shm segments and allows the clients to attach read-only.
A comment in the source code says:
/* On Linux, shared memory marked as "removed" can still be attached. Nice feature, because the kernel will automatically free the associated storage when the server and all clients are gone. */
Without this feature, i.e. on *BSD, SVR4 etc., if the X server terminates abruptly for whatever reason - immature driver, "kill -9", bugs, ... - it may leave 2 MB of shm segments lying around. And you need root permissions in order to clean them up.
The SysV IPC API consists of two layers: the shmget function, which maps 'key's to 'id's, and the other functions (shmat, shmctl etc) which operate on the ids. shmget is a naming service: the 'key' is like a filename, and the 'id' like an open file descriptor.
The kernel does proper resource management on file descriptors: you can read() from them after unlink(), and only when the reference count drops to 0 after unlink(), will the backing store on disk be freed. --> Low administration overhead for the user.
Linux has done the same kind of resource management in the past with shmids. If you don't want to continue supporting that, can you give the application developers a way to create shared memory with equally low administration overhead?
I'd be glad if you were moving towards shm_open/shm_unlink, because that has the right auto-cleanup functionality and therefore has low administration overhead:
The shm_unlink() function removes the name of the shared memory object named by the string pointed to by name. If one or more references to the shared memory object exist when the object is unlinked, the name is removed before shm_unlink() returns, but the removal of the memory object contents is postponed until all open and map references to the shared memory object have been removed.
But until that is implemented in kernel+glibc, we need the previous auto-cleanup feature.
Bruno
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |