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/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:19 EST