Re: local vs global object IDs

[Marcus Brinkmann]

On Wed, Jun 04, 2003 at 09:18:09AM +0200, Ludovic Courtès wrote:
> On Tue, Jun 03, 2003 at 06:04:32PM +0200, Marcus Brinkmann wrote:
> > I am aware of your concerns.  However, I don't think that in this case 
> > there is
> > a relationship to that discussion.  The global or local object ID component
> > is completely implemented within a server.  A persistent server will 
> > preserve
> > local _server side_ IDs as well as global server side IDs.
> > 
> > The issue you raised in your mail was about using global identifiers that
> > are not under the direct control of the server, such as its thread IDs.
> 
> I think the issue is more about using global IDs (on the client side) to
> refer to communication channels.

Well, that's ok by me.  The point I was trying to make is that global object
IDs are not global.  They are still local (to the server), but they are the
same for all users of the object.

> Thread IDs in L4 _are_ global, while
> ports in Mach are local (however, the issue in Mach is that one cannot
> control the way ports are allocated).

You can.  Unless mach_port_rename does not what you mean.

> Adding a 'persistent' bit to the version ID would work, but it has
> limitations.

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

typedef unsigned long long obj_handle_t obj;
obj = (server_thread_id << 32) | obj_id;

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/