| |||||||||||||
Ghosts of Unix Past: a historic search for design patternsGhosts of Unix Past: a historic search for design patternsPosted Oct 28, 2010 10:02 UTC (Thu) by Yorick (subscriber, #19241)In reply to: Ghosts of Unix Past: a historic search for design patterns by jengelh Parent article: Ghosts of Unix Past: a historical search for design patterns
Unfortunately the different forms of POSIX IPC (shm, mq) still use their own special-purpose namespaces. And POSIX message queues don't even use file descriptors so they cannot be polled by ordinary means - they do in Linux, but that's not portable.
Again and again, the same design mistakes, probably with excellent excuses every time.
(Log in to post comments)
Ghosts of Unix Past: a historic search for design patterns Posted Nov 1, 2010 8:21 UTC (Mon) by kleptog (subscriber, #1183) [Link]
Yeah, POSIX IPC is close, but not quite. While SysV shared memory is old, it still provides features that are not available anywhere else. The one I can think of off the top of my head is nattach, being able to examine a segment and see if it is still in use and by who.
This comes up every now and then when people want PostgreSQL to use POSIX shared memory or mmap(). Turns out that there is no portable replacement for all the features of SysV shared memory. Which means you could do it, but you lose a number of safety-interlocks you have now. And safety of data is critical to databases.
Ghosts of Unix Past: a historic search for design patterns Posted Nov 7, 2010 0:25 UTC (Sun) by kevinm (guest, #69913) [Link]
Isn't the entire idea of nattach inherently racy?
(If you don't care about that, you can just walk /proc/*/fd/* to count the number of opens, with either POSIX shm or mmap).
Ghosts of Unix Past: a historic search for design patterns Posted Nov 7, 2010 16:09 UTC (Sun) by kleptog (subscriber, #1183) [Link]
Not sure what you mean by racey. If you mean the value could change after you read it, sure, but that's not important. It could be that someone other than yourself tries to access the segment after you've checked you're the only one, but there are ways to ensure it's at least not another copy of yourself.
Given that is this situation attachments are created by fork() only (other than the initial one) if you have nattach == 1, you know there won't be another attachment other than by starting a complete new process. (The 1 is ofcourse yourself).
As for /proc/*/fd/*, that's hardly portable and more importantly, you're not required to have a file descriptor for a shared memory segment which means you need /proc/*/maps which is even less portable. Besides the fact that processes owned by other users are not examinable.
|
|||||||||||||