Re: local vs global object IDs

[Marcus Brinkmann]

On Wed, Jun 04, 2003 at 10:37:30AM +0200, Ludovic Courtès wrote:
> So long as the thread ID is hidden into an opaque data structure,
> it may be possible to customize the client communication library to do
> things that are needed only for persistent task.  So, yes, this would be
> persistence-friendly.

Ok.
 
> 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).

So we are using task IDs in the version field and the task server makes the
guarantee to you that a task ID is not reused if you have a task ID handle.
Note that if you are a persistent task, the task server must make the same
guarantee to you when you are restarted:  Either the task ID is used for the
same (persistent) task as it used to, or it is not used and won't be reused
until you release it.

In this model, the thread IDs are unimportant.  The task server can provide
you with a 1:1 mapping of all threads in a persistent task before and after
restart.  What is critical is to preserve task IDs, because they are global
IDs that are essential for IPC security (while in Espen's model, the thread
IDs are essential for IPC security).

This can be solved in the following way:  All persistent tasks get a task
ID.  The task server must ensure that it does not use the task ID of a
persistent task for anything else but this persistent task as long as there
are still tasks that hold task ID handles to the persistent task.  Usually
the only ones that can hold such handles under unnormal conditions are other
persistent tasks.  So essentially the task server handles for persistent
tasks have to be recovered at system startup.  In some way or the other,
parts of the task server must be persistent, too.

The only other guarantee the task server must make is that it doesn't use
thread IDs from the persistent task for other threads in the same persistent
task (this is easy to achieve).  Ie, if 25 is a thread number in task 16,
which is persistent, either no thread has 25 as number in the restarted task
16, or exactly the same thread as previously has this number.

As soon as you are at this stage, everything becomes easy.  Tasks can now
reliably detect that a persistent task was restarted, because sending the
message fails.  Now they can contact the task server and ask what the new
thread ID for this thread is.  The task server can provide it.  Note that
the task server can always try to allocate identical thread IDs, to boost
performance by making remappings unnecessary.

So I think that this part of the persistency problem can be completely
solved within the task server, by just adding a few functions and making a
few more guarantees, and in the client RPC stubs and object management
library to allow for remapping threads.

The only drawback is that task IDs for persistent tasks must prevail.  They
are a global resource.  But as there is probably only a finite number of
persistent tasks anyway, that is ok.  In fact, as you think of persistent
tasks as, well, to be persistent, it is ok if their task IDs are never
reused as long as the persistent task has a chance to be restarted.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/