SysV IPC: eyesore or misunderstood art?

[Jim Shankland]

In article <13601 at ncoast.ORG> allbery at ncoast.UUCP (Brandon S. Allbery) writes:
>AT&T added a new object space (IPC objects) for shared memory, message
>queues, and semaphores.  Presumably they had a reason not to want to use the
>existing object space of file descriptors.  I can imagine the following
>reasoning:
>
>* File descriptors aren't quite general enough to do what we want.
>* Changing fd's to be general (or perhaps flexible) enough will break things.
>* We can design an object space that *is* flexible enough.
>* Once we have done so, we can present them as separate object spaces for SVR2.
>* In future versions, we can start to convert file descriptors into a class
>  of IPC objects... eventually ending up with a single object space again.
>
>[etc.]

Naah.  They just didn't have the imagination to do it right.  The IPC
namespace business is an abomination.  I can't imagine it as a first
step toward a newer, grander vision.  (Of course, that's what they
said about *Dejeuner sur l'herbe*, too.)

Take a look at mmap() in SunOS 4.0 (it didn't actually originate with Sun);
that's a pretty clean way to do shared memory.  And I never have figured
out what message queues give you that you couldn't get by tuning up
pipe semantics a little.

To my mind, the SysV IPC stuff fairly screams:  "glued on to the system
at the last minute as an afterthought."  Your speculation on their line
of reasoning is novel, but even with my most charitable hat on, I just
can't see it.  Anybody who actually helped design this stuff care to
comment?

Jim Shankland
jas at ernie.berkeley.edu

"Blame it on the lies that killed us, blame it on the truth that ran us down"