[cap-talk] Evlan presentation slides

[Jed at Webstart]

At 12:17 PM 10/4/2006, Kenton Varda wrote:
>...
><http://evlan.org/files/cap-presentation-20060929/presentation.html>http://evlan.org/files/cap-presentation-20060929/
>
>Evlan itself, including complete source code for the compiler, VM, 
>web server, and Io Community Manager, is available from the web site:
>
><http://evlan.org>http://evlan.org
>
>I'd love to hear any feedback anyone has on it, positive or negative.

I (and I expect others) would be interested to hear how you got involved
with Evlan and where you anticipate that work leading you and it.

I'll pick up on a couple of things in this technical area:

>Orthogonal persistence:
>No filesystem; processes persist through system shutdown

Generally regarding processes persisting (e.g. through OS restart) I 
have quite a bit
of experience that I could draw from in a discussion of this area as the NLTSS
system that we designed and ran for some 10 years at LLNL:

http://en.wikipedia.org/wiki/NLTSS

had this process persistence property.  Generally a process can be 
represented as
a bunch of bits (registers, memory, state, etc.) which can be stored in a file.
However, when a process is running it's state is much more dynamic.  During
a clean system shutdown of course a processes state can be written to a
file (e.g. disk) and then picked up again when the system is restarted.

If a system crashes the situation is a bit more difficult.  In that case
it seems to me you are faced with three possibilities:

1.  Destroy and/or reinitialize the process,
2.  Reset the process to a previous state (e.g. that on rotating storage), or
3.  Try to recover the process from what's in memory.

In our NLTSS system at LLNL we did all of the above under different 
circumstances.
#3 is of course the best if it's possible.  Generally we did some consistency
checks on the process state and then restored it from what was in memory.
There is of course a hazard with this approach depending on what caused
the system crash, so it must be done carefully.  Resetting to a previous state
is only reasonable if the process state is changed to indicate that 
it is no longer
running and may only be suitable for recovery.  We could reinitialize processes
that we knew something about (e.g. 'system' processes like the file server,
process server, etc.), but sometimes had to destroy hopelessly damaged
processes.

One issue we found important regarding process persistence was that
of timeouts and the related issue of network connections.  Naturally if
a process was involved in an algorithm that depended on timing (e.g.
a protocol exchange with timeouts), then being stopped during a system
restart could break whatever protocol exchange was taking place.
In our system we went to extreme lengths to try to insure that programs
didn't depend on timing.  For example, we instituted what we called
"good guy" timers in servers.  If a server was involved in an exchange with
some other process (e.g. even something as simple as sending a reply
to a request) in general it can't afford to wait forever to complete the
exchange (e.g. to send the reply).  That is a situation where one can
imagine using a timeout (if the reply can't be sent in so much time,
cancel the send and give up).  What we did was to establish timeouts
in such situations, but we didn't actually give up unless or until both
the time had elapsed and the resources (e.g. a send buffer or thread)
were needed for some other activity.  In practice this meant that servers
usually waited essentially forever for client processes that may have
been stalled by a system shutdown - unless system resources became
scarce.  For us this made dealing with timeouts much more tolerable.


On the topic of "No filesystem" - I wonder why that?  A filesystem seems
to me a very natural and useful thing.  It also seems to me that a filesystem
arises very naturally from the object/capability model.  A "file" is an object
that can store (e.g. for reading and writing) bits and a "directory" is an
object that can store references to other objects (e.g. by name).  This model
naturally creates a directed graph structured file system, e.g. along the
lines of:

https://wideword.net/doc/i%2Bej6NZzbDWtc2k444Nk%2FQ%3D%3D

though the naming can of course be done in many ways and the
object/capabilities can be protected in many ways.

I guess what I'm saying is that I don't see "No filesystem" as a feature
of an object/capability system but rather as a sad lack.

Under "Real World Use" you refer to the Io Community Manager and
some Web sites.  Can you describe how Evlan is used for these
applications?  Is that "Real World Use" chart the last?  I admit I
had some trouble viewing this set of charts.  Perhaps the exchange
in this area could tie into my initial general question about your
involvement with Evlan Kenton.

--Jed http://www.webstart.com/jed/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20061005/c63168f5/attachment.html