[Top][All Lists]
[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
- Hurdish applications for persistence, Marcus Brinkmann, 2005/10/10
- Re: Hurdish applications for persistence, Ludovic Courtès, 2005/10/11
- Re: Hurdish applications for persistence,
Jonathan S. Shapiro <=
- Re: Hurdish applications for persistence, Alfred M. Szmidt, 2005/10/11
- Re: Hurdish applications for persistence, Bas Wijnen, 2005/10/11
- Re: Hurdish applications for persistence, ams, 2005/10/11
- Re: Hurdish applications for persistence, ness, 2005/10/11
- Re: Hurdish applications for persistence, ams, 2005/10/11
- Re: Hurdish applications for persistence, ness, 2005/10/11
- Re: Hurdish applications for persistence, ams, 2005/10/11
- Re: Hurdish applications for persistence, ness, 2005/10/11
- Re: Hurdish applications for persistence, ams, 2005/10/11
- Re: Hurdish applications for persistence, ness, 2005/10/11