Re: Hurdish applications for persistence

[Ludovic Courtès]

Hi Marcus,

Good to hear from you and about persistence.  ;-)

Marcus Brinkmann <address@hidden> 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