Greg A. Woods writes:

>What do _you_ mean by "multiplexed"?  And are you talking explicitly
>about message queues in particular?

Yes, of course.

>> identifiers & resources hang around when
>> process exits abnormally,
>
>that's often thought of as a feature....

A feature?  Resources that don't get freed because a per-process
reference count is missing?  Just imagine what the situation would
be if files weren't closed when a process terminates (involuntarily).

>> sometimes until the system is rebooted (you
>> can't always ipcrm),
>
>Implementation bugs are not API deficiencies or design flaws.

It's not an implementation bug if you don't know if the identifier
you see in ipcs is still in use (and deleting it might crash the
process using it) or if it's free (and thus could safely be ipcrm'd).

>Indeed POSIX IPC mechanisms are far more desirable, but also equally
>non-portable until a majority of modern OS releases catch up to
>P1003.1-2001 and are deployed in a significant number of installations.

Of course a fully implemented, sensible, standardized API is
preferrable in the long run.  I don't know the story of the SysV IPC
stuff but it's very likely that it was a quick ad-hoc thing written
without proper design in order to provide the necessary IPC mechanism
for some specific software that needed to be written.  It predates BSD
sockets in any case (wasn't it already available in SysIII?)

-- 
  Matthias Buelow;  mkb@{mukappabeta.de,informatik.uni-wuerzburg.de}