Here's the flame everyone's asking for (was Re: Shared Memory in BSD4.3 is lacking?)

[Mike Ditto]

Posting-Front-End: GNU Emacs 18.41.10 of Fri Oct  2 1987 on kenobi (usg-unix-v)


In article <2009 at ho95e.ATT.COM> wcs at ho95e.ATT.COM (Bill.Stewart) writes:

> Ok, I'll flame!  What's wrong with System V shared memory?

Hmm... asking for trouble...  :-)

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":

	"/dev/kmem" could be a named shared memory segment, which,
	like all shared memory segments, could be accessed via
	lseek/read/write or mapped into a process's address space.

	IPC objects could have names in the filesystem, and be
	manipulated with normal commands.  You could use "rm" to
	delete a message queue, or "ls" to see which ones exist,
	just like you can see which devices are in /dev.

	You could use these names as arguments to programs, or put them
	in the environment.  For example, consider a multi-user
	conferencing system (like Compuserve "CB") that looked at the
	"CONFCHANNEL" environment variable for a name of a default
	shared memory segment to communicate through.

	The shell could use normal I/O redirection to connect programs
	via IPC.

	Shell scripts could easily use IPC.

	And so on...

Not all the IPC functions are directly mappable to read, write, etc.,
(what should reading from a semaphore do?) but it still wouldn't hurt
to give them file descriptors for the reasons above.  It's not any
different than having a line printer device which does nothing useful
in reply to a read() system call.

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.

>From a practical point of view, it doesn't make much difference.  System
V IPC provides sufficiently powerful facilities to be very useful and
not too difficult to use, (once you are familiar with it, which won't
happen from reading the documentation).  I just think it could have been
made more consistent with the Unix philosophy without any loss of
functionality, and it would have opened up some interesting
possibilities like the examples above.

					-=] Ford [=-

"Well, he didn't know what to do, so	(In Real Life:  Mike Ditto)
he decided to look at the government,	ford%kenobi at crash.CTS.COM
to see what they did, and scale it	...!sdcsvax!crash!kenobi!ford
down and run his life that way." -- Laurie Anderson