Consequences of Choices

[Reginald S. Perry]

I have been following the decision of which OS substrate to use and it
seems that one thing has been overlooked. If you choose the wrong
substrate you probably will not be able to unhinge yourself from the
results of that choice. This will especially be true if you write this
persistent store. 

The thing I am looking at is the Unix signal semantics. I wouldn't
think that if you were designing a LispOS from the ground up that you
would want these semantics as they seem to be inconsistent with having
multiple threads of control and exceptions. By this I mean that having
these things on top of the signal semantic makes for clunky
programming and awkward designs for very useful things like
asynchronous I/O. I believe that this is
because the Unix kernels have implicitly relied on the process
model. Typically the kernel address space contained on stack for every
thread in the system. Now recently methods have been devised to get
around this problem. Things like Solaris LWPs and multi level thread
methods like in Digital Unix, and Scheduler Activations which I think
SGI uses. But I would think that LispOS would need more flexibility. I
believe that if we choose to build on the process model alone that
there will be some OS level inefficiencies that we will not be able to
get rid of.

I would like to know what people think about this. Here is the
abstract and a pointer to the paper that got me thinking about this:


Richard P. Draves, Brian N. Bershad, Richard F. Rashid, Randall
W. Dean. Using Continuations to Implement Thread Management and
Communication in Operating Systems.
ftp:/afs/cs/project/mach/public/doc/published/threadmgnt.ps 
Technical Report CMU-CS-91-115, Carnegie Mellon University, October
1991. Also appears in the proceedings of the Thirteenth Symposium on
Operating Systems(SOSP).

We have improved the performance of the Mach 3.0 operating system by
redesigning its internal thread and interprocess communication
facilities to use continuations as the basis for control
transfer. Compared to previous versions of Mach 3.0, our new system
consumes 85% less space per thread. Cross-address space remote
procedure calls execute 14% faster.  Exception handling runs over 60%
faster.

In addition to improving system performance, we have used
continuations to generalize many control transfer optimizations that
are common to operating systems, and have recast those optimizations
in terms of a single implementation methodology. This paper describes
our experiences with using continuations in the Mach operating system.


-------------------
Reginald S. Perry                      e-mail: perry@zso.dec.com   
Digital Equipment Corporation
Performance Manager Group	               
http://www.UNIX.digital.com/unix/sysman/perf_mgr/pmweb/index.html

My opinions are barely my own. Clearly Digital wants nothing to do with them