[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: local vs global object IDs

From: Ludovic Courtès
Subject: Re: local vs global object IDs
Date: Wed, 4 Jun 2003 10:37:30 +0200
User-agent: Mutt/1.5.3i


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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]