SysV IPC: eyesore or misunderstood art?

[Malaclypse the Elder]

In article <837 at mtxinu.UUCP>, ed at mtxinu.COM (Ed Gould) writes:
> 
> The history of Unix development and support gives some clues to
> understanding some of the (mis)features in System V.  While AT&T was
> prohibited, by a consent decree signed between AT&T and the Justice
> Department, from being in the computer business, there was a group with
> in the (then) Bell System called the "Unix Support Group" (USG).  USG's
> job was to support Unix for the Bell Operating Companies and other
> internal Bell System uses.  They were not trying to develop
> general-purpose systems, but to meet the specific needs of their
> users.
> 
as i remember it, because of the void in such services, there were
a number of different implementations of shared memory and messages.
the bell labs comp centers (who were one of the largest "users" of
system III at the time) were threatening to adopt the ipc implementations
of the computer center in columbus (i believe).  this perhaps forced
the USG to design something of their own.  i never used the columbus
implementation of ipc (i think it was called MAUS) but it was the
perception that what the USG implemented was more general.

i'm not sure why they did not choose to FORCE a mapping between filesystem
names and message queues or semaphores since one of the recommended
ways to generate a unique key to create these things is to use ftok().
having file descriptors would also have made it easier to do polling
for input from either message queues, semaphores or regular files.
then again it isn't to late to do that and have all the shm_ops and
the sema_ops just library calls for compatibility.  then again maybe not.

all this is from cloudy memory.  my memory of events before DIVESTITURE
are hazy (perhaps also idyllic).

danny chen
att!hocus!dwc