Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 v7 ucbtopaz-1.8; site ucbtopaz.CC.Berkeley.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!harpo!decvax!ucbvax!ucbtopaz!mwm
From: mwm@ucbtopaz.CC.Berkeley.ARPA
Newsgroups: net.micro
Subject: Re: What Unix needs is ...
Message-ID: <905@ucbtopaz.CC.Berkeley.ARPA>
Date: Thu, 25-Apr-85 18:49:02 EST
Article-I.D.: ucbtopaz.905
Posted: Thu Apr 25 18:49:02 1985
Date-Received: Sat, 27-Apr-85 04:31:39 EST
References: <381@wdl1.UUCP>
Reply-To: mwm@ucbtopaz.UUCP (Praiser of Bob)
Organization: Missionaria Phonibalonica
Lines: 49
Summary: 

John Nagle writes that shared memory would cause portability problems
even among machine that shared that shared memory model. He goes on to
suggest improvements to the pipe mechanism that, while being an
excellent performance enhancement, don't change the semantics, and hence
don't solve any of the basic problems with pipes.

First, the "problem" with shared memory:

>      While UNIX needs better interprocess communication, a shared-memory
>facility will strongly limit the portability of programs, because the
>semantics of the underlying machine will become much more visible to the user.
>UNIX programs do not at present need to have the size of a unit of memory
>allocation, the semantics of the memory management unit, or knowlege of the
>number of CPUs in the system designed into them.  We should not force them to.

All correct, except that the semantics of the underlying machine don't
need to become visible to the user, any more than they needed to become
visible for the sbrk system call. I haven't seen AT&T's implementation
of shared memory, but if the semantics aren't like (or better than) the
following, then something is badly broken:

	Two co-operating processes request shared memory,
	The system verifies that everything is kosher, and
	decides how much memory they have asked for.
	It then allocates a segment at least that big, and
	returns it to the processes.

Nothing at all needs to be known by the programs about the mmu for this
to work. The synchronization problem is still unsolved, but that's not
new for Unix. I'd suggest a call to lock/unlock a shared segment in
various ways. Once again, nothing about the semantics of the machine
need to be visible to the program. Of course, you can still hang
yourself, but Unix has never been good about protecting code from
itself - which is a good thing.

As for pipes, they may be sufficient, but they have two serious
problems. First, they only work between processes with a common ancestor
that planned for this event. Second, they are inadequate to handle the
problem of data that needs to selectively fed through a process more
than once. The common example of this is the command line to typeset a
matrix equation that has equation as elements (a common happening in
linear algebra):

	eqn filename | tbl | eqn | troff

So, while John's suggested changes to pipes would be nice, Unix still
needs a different IPC facility.

	<mike