Re: Persistent object handles

[Espen Skoglund]

[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.

You don't really need to use the same thread ids (depending on how you
design the system of course).  All you need to do is for the
persistent task to detect that a new instance of some server is
started, and then reestablish the connection.  Detection can be
achieved using version identifiers.  Reestablishing the connection can
be as simple as recording the new thread identifiers, or use some
special protocol to propagate client state to the new server.  The
reestablish code must be part of the client (i.e., error recovery
after a failed IPC operation), but might be generated automatically by
an IDL compiler.  More complex reestablishment is needed whenever
servers are stateful.

If a transient stateful server is going to serve persistent clients,
care must be taken to ensure that it is indeed possible to reestablish
the client connection if the system shuts down.  Obviously, designing
transient servers so that it is possible to reestablish connections
with persitent clients is not always trivial, and providing support
for persistence this way is not very transparent to the system
programmer.  For this reason, the focus of the paper you referred to
was more on providing orthogonal persitence on larger, more or less
self contained subsystems.

        eSk