Re: local vs global object IDs

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> > What you say makes sense to me. I think task id:s should be an
> > exception, though, as we want them encoded into the (global) thread
> > id:s, right?
> 
> Task IDs != Object IDs.
> 
> A task gets an ID.  However, the task itself can be represented by an object
> with a different (local) ID.  The task ID object that allocates references
> to a task can be yet another object represented by a local ID as well.

Well, you could have task handles use local id:s to identify a task,
just like any other handles (in the local id model). However, any task
that owns such a handle will likely also need the tasks global task
id. In particular, this is true for a server, who needs the caller's
object id, and the global task id (extracted from the caller's thread
id) to check, for each ipc, that the caller owns a valid handle. This
is unlike most other servers, where any internal global identifier for
objects is purely an implementation detail of the server, which
clients shouldn't know about.

So I guess it's no big deal, if we have local id:s for the task
server, most tasks that get a task handle will issue
get_global_task_id to the task server (which is unnecessary if there
are no local task id:s), but that's about it. The task server, like
any server, has the freedom to issue distinct local id:s, or use
global id:s only, whichever is most convenient.

A task handle will then have the form

  <task-server-thread, local-id, global-id>

where the global id is redundant in principle (one can always use
get_global_task_id to get it from the first two elements). And the
task-server-thread is also redundant in principle, as the task server
should use a well-known thread-id (or thread-id:s, if there are
several cpu:s).

A general object handle (in a client) will have the form

  <server-thread, local-object-id, server-task-handle>

The corresponding handle-record on the server side will have the form

  <client-global-task-id, local-object-id, client-task-handle,
   real-server-object>

For access control, the server needs to be able to quickly look up
this handle-record given the first two elements, which are provided
with each received ipc message.

To me there seems to be an essential difference between task handles
and other object handles. This difference should probably be hidden
somewhere so that ordinary programs can treat all handles in the same
way, but it's not obvious to me what's the right place for that
abstraction.

Regards,
/Niels