Unix philosophy

[Guy Harris]

In reply to several points on interprocess communication:

	But sometimes the kernel must be changed, because there are certain
	things that one just can't do in a subroutine library (although
	it is amazing to me that Newcastle implemented a fully distributed
	file system better than Sun's 4.2 without touching the kernel).
	The best example is interprocess communication.

4.2BSD already has what seems to be a fairly decent IPC mechanism, with its
sockets.

	everybody and his dog seems to have their own way of dealing with
	interprocess communication. these days, I think that tunis is
	maybe the way to go. interrupts are converted to messages, and
	there is message handling in the kernel. Unfortunately, this is
	not unix. It is too bad that interprocess communication was a very
	new idea when Dennis Ritchie and Ken Thompson were designing the
	first unix.

I'm not sure it was really that new an idea; several real-time minicomputer
operating systems had message send/receive facilities in the mid '70's.
Unfortunately it is true, though, that we have a proliferation of IPC
facilities.  I suspect the 4.2BSD and USG 5.0 mechanisms can be twisted enough
to be based on one common system if someone wants to work hard enough (start
by taking the 4.2BSD system, add a new domain where the socket address is the
32-bit unique identifier used by 5.0, and add in whatever stuff is needed to
support the 5.0 facilities.  The 5.0 system is based on an "IPC descriptor"
which is like a file descriptor, sort of, so the 4.2BSD descriptors may be
usable here.).

	I'm no expert on the requirements and applications of interprocess
	communication (IPC) but I do know that any reasonable definition of
	what constitutes an IPC mechanism would include the now widely acclaimed Unix
	pipeline.  Therefore it depresses, even saddens, me to hear so many
	people talk about ways to do IPC in Unix without any discussion of
	pipelines (except to immediately dismiss them as too weak).

	P.S.  Here's a concrete proposal (someone must have already thought of
	this).  Why not let pipelines have names that appear in the file system
	as a new kind of directory entry in addition to files and directories.
	Then they can live and die independently of processes and any process
	that knows the name of a pipeline and has the right permission can read
	or write to it.

Somebody did think of that; System III and later USG releases of UNIX implement
pipes as a new type of inode - a "fifo".  A pipe is just a fifo made up on the
fly with no directory entry pointing to it.  You connect to a fifo by opening
it like a regular file.

However, the inability for unrelated processes to use pre-S3 pipes isn't pipes'
only problem.  They cannot function in a record-oriented (i.e., message-
oriented) fashion; any record separators or lengths must be provided by the
process writing to the fifo.  This means a malicious or deranged process can
foul up everybody else by writing an incomplete record to the fifo; I don't
know whether there's a protocol which guarantees this won't happen, but even
if it does exist it would probably add overhead.  Furthermore, multiplexing
several communications over a fifo is difficult.

4.2BSD took the opposite tack from generalizing pipes.  They added a new IPC
mechanism and implemented pipes as a special case of it.

The System V message queues are different beasts from pipes entirely.  They
are message-oriented (rather than stream-oriented) and support multiple readers
and writers (you can put a "tag" on a message when you send it and can ask for
only messages with certain tags when you receive a message from a queue).

	Guy Harris
	{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy