Re: local vs global object IDs

[Ludovic Courtès]

Hi,

On Wed, Jun 04, 2003 at 10:04:02AM +0200, Marcus Brinkmann wrote:
> You can.  Unless mach_port_rename does not what you mean.

Ok, I just didn't know about it. :)

> Yeah, well.  I am not really worried, because the server thread IDs will be
> mostly hidden in handle types and object mangement libraries.  The same is
> true for the basic protocols.  All of this has to be rewritten anyway when
> you want to add persistency.  If you have any particular suggestions how to
> make the current proposals more persistence friendly they are certainly
> welcome.  However, such a change must fulfill two conditions: It must not
> impose a large overhead on communication between transient tasks, and it
> must not break the design by large (ie, something like fetching the thread
> id from a name server or such is not acceptable at this stage of
> development).  Otherwise, the only main thing what we can do is that except
> for the object management code itself, we are not exposing the thread id of
> servers for objects directly, but always hidden in a more abstract type like

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.

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

Thanks,
Ludovic.