Re: local vs global object IDs

[Espen Skoglund]

[Marcus Brinkmann]
>> One thing a persistent communication client library could do is add
>> information in this data structure on whether the thread ID refers
>> to a persistent task and what its PID or path is.  In case an IPC
>> fails because the thread ID is invalid, it could use this
>> information to try to get the new thread ID for this task (by
>> asking the relevant server).

> In Espen's model, you would use the version ID of a thread to notice
> if the old thread died.  I believe this to be dangerous on 32 bit
> architectures, as 14 bits are very easily overrun, and more complex
> strategies (not reusing thread numbers for a while if all version
> IDs have been used) are just that: more complex and probably a huge
> performance issue (you want to keep thread numbers low and
> unfragmented to preserve kernel memory).

In the model I suppose you are referring to, more or less the whole
system would be perstistent.  Only certain servers like device drivers
and the checkpointer itself would not be persistent.  The version ID
check in this model is only performed for communication between a
persistent and a transient task, and unless you reboot your machine or
otherwise restart, e.g., your device driver exactly 2^14 times between
two consecutive server requests you are all fine.

If your model is that only a few tasks are persistent, then you have a
whole lot of other problems to deal with.  I.e., you probably have
many more open connections/dependencies between transient and
persistent tasks.  Making orthogonal persistence completely
transparent in such a system is difficult.

        eSk