Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!felix!dhw68k!david
From: david@dhw68k.cts.com (David H. Wolfskill)
Newsgroups: comp.unix.wizards
Subject: Re: Here's the flame everyone's asking for (was Re: Shared Memory in BSD4.3 is lacking?)
Message-ID: <5580@dhw68k.cts.com>
Date: 3 Mar 88 14:42:32 GMT
References: <9100@ism780c.UUCP> <2329@umd5.umd.edu> <2009@ho95e.ATT.COM> <43@kenobi.UUCP>
Reply-To: david@dhw68k.cts.com (David H. Wolfskill)
Organization: Wolfskill residence; Anaheim, CA (USA)
Lines: 68

Some musings from a non-wizard (meaning me, not Mike Ditto):

In article <43@kenobi.UUCP> ford@kenobi.UUCP (Mike Ditto) writes:
]....
]Actually, I like System V shared memory.  It has many useful features
]and I have used it very successfully in several projects.  However, I
]do have a few observations about System V IPC in general.

]On Berkeley Unix, the primary IPC mechanism (the socket) is very
]nicely implemented in a way consistent with the previously existing
]I/O facilities.  In particular, it is accessed in the same way as
]files and other I/O: with a "file" descriptor.  In fact, the socket
]completely replaces the less general pipe mechanism.  A socket
]descriptor can be accessed with the "read" and "write" system calls
](although socket-specific calls are also available).  On any
]descriptor (file, device, or socket) the fstat() system call can be
]used to determine what type it is, but few programs need to know.

]With System V IPC (Shared Memory, Semaphores, and Message Queues)
]special system calls are needed not only to create the "ID"s, but also
]to access them.  These special access methods are necessary, of
]course, but why not allow the normal access methods to work as well?
]Why can't you read(2) and write(2) to message queues?  Why can't you
]have a named semaphore or shared memory segment.  Why can't you use
]fcntl(fd, F_SETFD, arg) to specify whether shared memory should be
]inherited by exec(2)'d processes.

]If System V IPC had been done "right":
[several suggestions about how programs could (for example) access IPC
objects as if they had properties like those of files....]

]All the existing capability could have been provided, while giving a
]more consistent view of the IPC mechanisms.  BSD Unix allows normal
]read/write access to sockets, but provides additional system calls
]that allow more detailed and socket specific control over I/O.  All
]the old articles about Unix from Bell Labs in the seventies boasted
]about the revolutionary idea of I/O and pipes that look the same as
]file access.  And yet AT&T didn't live up to that concept in their IPC
]enhancements.

]....

Would it be feasible for some (future) implementation of some sort of
UNIX (or POSIX or GNU or...) to possess system calls with the
capabilities of System V IPC, and also be able to be accessed as Mike
suggests?

After all -- assuming (!) that this is actually something that this is
doable -- this would be making a superset of the System V functionality.
(I'm thinking here about the analogy of pipes being implemented in BSD
via sockets, for example.)

Now, whether or not it would be *worth* the effort is another issue --
possibly with a different answer....  (Probably with different answers
for different situations, for that matter....)

My (admittedly limited) experience with UNIX is with a flavor that is
System V with a fair amount of BSD extension, including sockets.

Naturally, I have no access to source for either BSD socket or System V
IPC kernel support, so I'm not in a position to judge whether or not any
of this really would be feasible....

Does this seem reasonable?

david
-- 
David H. Wolfskill
uucp: ...{trwrb,hplabs}!felix!dhw68k!david	InterNet: david@dhw68k.cts.com