Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site wdl1.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!hao!hplabs!hpda!fortune!wdl1!jbn
From: jbn@wdl1.UUCP
Newsgroups: net.micro
Subject: Re: What Unix needs is ...
Message-ID: <381@wdl1.UUCP>
Date: Mon, 22-Apr-85 23:16:25 EST
Article-I.D.: wdl1.381
Posted: Mon Apr 22 23:16:25 1985
Date-Received: Fri, 26-Apr-85 22:10:17 EST
Sender: notes@wdl1.UUCP
Organization: Ford Aerospace, Western Development Laboratories
Lines: 65
Nf-ID: #R:brl-tgr:-999800:wdl1:1400042:000:2867
Nf-From: wdl1!jbn    Apr 22 19:54:00 1985


      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.
The pipe mechanism has the virtue of simplicity.  With pipes and intermediary
processes, elaborate multiprocess systems can be constructed; the fact that
this mechanism is slow reflects some design decisions made when memory was
very expensive.  Pipes are actually implemented as circular buffers in small
files; normally the I/O does not actually take place, but all the machinery
of the buffer cache is exercised for each pipe operation.  We should be able
to do better today.
      Pipes need to be redesigned and reimplemented.  A reimplementation 
along the following lines might be useful.

	1.  Opening a pipe acquires a suitable amount of memory which is
	    held until the pipe is closed.  Suitable system, process, and
	    user quotas may be applied if desired.

	2.  Pipes are implemented as circular buffers in system memory.

	3.  If a write to a pipe fulfils the following conditions,

	    -- after the write, less than one I/O buffer size of space
	       will be available in the pipe,

	    -- there is a process waiting on a read from the pipe,

	    -- the waiting process is otherwise ready to run, and

	    -- the reading process does not have a lower priority than the
	       writing process, 

	    then control should immediately pass to the reading process rather 
	    than returning to the writing process. 

	4.  If a read from a pipe fulfils the following conditions,

	    -- after the read, less than one I/O buffer size of space
	       will be in use in the pipe,

	    -- there is a process blocked on a write to the pipe,

	    -- the writing process is otherwise ready to run, and

	    -- the writing process does not have a lower priority than
	       the reading process,

	    then control should immediately pass to the writing process rather
	    than returning to the reading process.

     The effect of this will be to produce a much tighter relationship between
the reader and writer; simple producer-consumer relationships will not cause
cycling of the scheduler, although context switches will still be necessary.
This will produce almost the effect of a coroutine-type process switch, as
is used with good effect in Modula.  Yet none of this will be visible to the
user, except as improved performance.

     Not being in the business of modifying UNIX, I have no plans to implement
this.  But I would appreciate hearing from anyone who does.

						John Nagle