>> A new _flat_ namespace for each resource.
>> A new flat namespace _with human-meaningless names_ for each resource.
> Have you never heard of inode numbers?   :-)

Certainly.  How many APIs use them?

> Perhaps you're not aware of ftok(3) and its use to map normal
> pathnames into IPC identifiers?

Certainly.  How does it avoid collisions?  (Hint: it can't.  There can
be, and on large systems not too infrequently are, more files than
there are possible IPC IDs.)  How is there any excuse for tying this
new namespace to the existing filesystem namespace?

>> The worst of both the persistent and transient worlds: no cleanup on
>> process exit - but loss upon rebooting.
> I think you've mis-interpreted what I believe was a design goal of
> SysV IPC.  The IPC entities are not supposed to go away when the last
> process exits -- they are supposed to persist so that a process can
> come along later and re-attach to them.

It's fine to have that option.  It's broken to have that as the only
option.  (Whether it should be the default is debatable.)

> There's nothing fundamentally wrong with them disappearing on reboot
> though -- in that sense they are no different than a memory
> filesystem.  (or pipes).

Pipes do not have names.  Memory filesystems, yes, and that's one
reason I don't use memory filesystems.

>>> it is unfortunate that you can't use poll() on message queues (sysV
>>> or posix).
>> Unfortunate?  I would call it fatal.
> poll() came along to the systems in question quite a bit later than
> message queues

...so?  Taking an OS whose unifying concept is "everything is a file
descriptor" and creating three new object types that can't have file
descriptors associated with them is a good way to create problems.

> Luckily POSIX message queues have a way to establish a notify
> callback function that will be called just like a signal handler

Gah.  We need to get away from signal handlers.  Or else we need an
environment (language and OS) better suited to them.  Getting away from
signals was one of the things that made me implement AF_TIMER sockets.
(Another was the insanely small number - one - of possible outstanding
timeouts with the signal-based timer facilities.  The third was the
desire to try adding a new type of socket.)

> (though the notifier does have to be re-established every time it
> triggers and that must be done before the queue is read else a
> message could appear before the notifier is set and it would never
> trigger until the queue was emptied).

So they not only repeated the mistakes of signals, they repeated the
mistake of making them unreliable.

And this is the API you are holding up as a paragon of goodness??  I
shudder to imagine your idea of a bad API.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B