Re: Persistent object handles

[Ludovic Courtès]

On Sun, Jan 05, 2003 at 06:54:58PM +0100, Niels Möller wrote:
> How big are the L4 tread id:s? Would it work to partion the
> version-number space into two parts (using one bit of it), and use
> that to identify persistent threads?

The L4 X.2 specs says that the thread ids should be 32-bit long, where 14
bits are available for a version number (on a 32 bit machine).  Anyway, you
could probably user the version number to distinguish between persistent
and non-persistent threads but that's not enough: You can't make sure that
you will be able to assign the same thread with the same id upon recovery.

> Ideally, you'd prefer that the communication partners of a thread not
> need to know if the thread they're talking to is persstent or not. If
> you need some extra level of redirection for persistent threads, that
> might not be possible.
> 
> Hmm. Or you could have each persistent thread have a non-persistent
> proxy. All non-persistent threads would only need to know the proxy.
> Persistent threads/tasks would need some mechanism to locate each other and
> to create proxies at system startup, but non-persistent tasks need not
> know anything about that.

Yes, that's the way I was thinking about it.  The idea is pretty much like
Fluke's nesters [1].  All persistent task are created in their own
persistent environment (almost a subhurd) with their own root filesystem
(in fact a proxy to the real root so that it can know all existing
communication channels created by persistent tasks and decide which ones to
include in the checkpoint image) and their own proc server.  These two
servers are not persistent but they need to have a PID in the persistent
world so that communication channels between their persistent tasks and
them can be made persistent.

Thanks,
Ludovic.

[1] http://www.cs.utah.edu/flux/papers/fluke-rvm-abs.html