Hi Marcus, Good to hear from you and about persistence. ;-)
Marcus Brinkmann <[EMAIL PROTECTED]> writes: > Interludium: Orthogonal persistence. > > Note that not the whole system needs to be persistent to make this > work. "Orthogonal persistence" were only the active translator tasks > and their execution environment are persistent would suffice. Persistence of a program's set of capability emphasizes the need for the use of local capability /names/ (as proposed in L4sec), as Jonathan explained earlier this week[0] and as I discussed some time ago[1] (sorry for citing myself). 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). 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. 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. But what if the servers implementing B's capabilities vanish after B was checkpointed and before it is restarted? This seems to be quite complicated. I bet system-wide persistence is easier to achieve than partial persistence... Thanks, Ludovic. [0] http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00016.html [1] http://lists.gnu.org/archive/html/l4-hurd/2003-01/msg00002.html _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
