Consequences of Choices

[Dwight Hughes]

| From: Reginald S. Perry <perry@zso.dec.com>
|
| 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.


This is still a concern of mine and why I originally supported the Flux
OS Toolkit approach. I think your concerns are quite valid.

However, for pure pragmatism in getting this project started, I think
the approach of using a Linux/FreeBSD type base to begin with has too
many advantages for us to ignore.

1) we can use the un*x-based tools to best advantage, of which CMU-CL is
one (for now);
2)working with the innards of the un*x kernel will give us some real 
knowledge of what *must* be developed for the LispOS kernel -- 
getting to a "can't get there from here" position in development should
clarify things enormously;
3) the LispVM project would greatly benefit from this knowledge, since 
they will be working *within* the confines of the un*x OS - clean 
techniques to get the best performance (minimal kernel extensions or 
patches or whatever) would be extremely useful;
4) we can, with a bit of care, isolate most of the un*x fundamentals
behind various defined objects in the CL universe -- giving us the
ability to create some of the higher level api's -- the object's job
would be simulation, however inefficiently, of the equivalent fully
developed Lisp object's functionality;
5) by pushing 4) as far as we can we can, to lower and lower levels
of our LispOS kernel, it allows us to go through cycles of design and
insight much quicker than we could on a sort-of running LispOS kernel,
where we would be re-weaving the carpet as we stand on it;
6) it would more quickly allow development of the exported kernel api
to enough detail that higher level code, applications, utilities, or
whatever could begin to be developed, and even tested, even if in
slo-mo mode;
7) the definition of a VM interface would also be accelerated, since
the division between OS and application or interface would be more
quickly developed to a point of reasonable stability.

Henry Baker, I believe, talked earlier about using continuations in
the same context as the paper you reference (I saw your later correction
to the pointer -- I can get to the site but so far I can't download it).

-- Dwight