l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hurdish applications for persistence


From: Jonathan S. Shapiro
Subject: Re: Hurdish applications for persistence
Date: Tue, 11 Oct 2005 09:51:02 -0400

On Tue, 2005-10-11 at 10:06 +0200, Ludovic Courtès wrote:
> Suppose that B got its capability set from A.  Upon recovery of B, A
> (which may be the "session server") will have to copy back all these
> capabilities to B.  Additionally, B will have to make sure that the way
> it names these capabilities is the same as before it stopped (in L4sec's
> model, this would mean re-mapping things to the same local names; I
> don't know if/how EROS allows applications to choose the way they name
> capabilities).

For a while, I believed that this was a good design, and you may notice
that early writings about Coyotos say we plan to do this. I subsequently
decided that EROS had done this right, and that my concerns with the
EROS approach simply needed more careful engineering attention.

In EROS, capabilities are named by their C-space address, so yes, the
names are local. There is no need to re-establish a file name space in
the sense that you describe.

> Now, if application B, besides its initial capabilities, got a number of
> capabilities from various different servers, then restoring them upon
> recovery is more complicated.  Especially since those servers may have
> "garbage collected" the objects underlying B's capabilities when they
> got notified of B's death.

This depends on how you implement persistence. If you implement
machine-wide persistence, then of course it is very simple.

> One possibility to this problem might be for applications to copy any
> capability they get to their associated session server.  This would
> prevent garbage collection.  Upon recovery, applications would ask their
> capabilities back from their session server.

I believe that this could be made to work. It was the design we intended
for Coyotos. It is much more complicated than I initially appreciated. I
concluded that I am not good enough to get this design right, that the
result would be very prone to error, and that it would be very easy to
corrupt such a system (in the sense of data structure corruption).

> This seems to be quite complicated.  I bet system-wide persistence is
> easier to achieve than partial persistence...

Good thing we know how to do it, then. Heck. Some asshole wrote a paper
about it just a few years ago. All we need to do is plagiarize
effectively. :-)

shap





reply via email to

[Prev in Thread] Current Thread [Next in Thread]