Re: local vs global object IDs

[Marcus Brinkmann]

On Tue, Jun 03, 2003 at 09:14:34PM +0200, Niels Möller wrote:
> 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.

There are both ways.  If you create the task ID handle, you know the task ID
in advance.  If you receive a task ID handle, you will also get a thread ID
for this task, so you can get the task ID from that, although a consistency
check must be done to protect against bugs and malicious servers.

So, the only thing you do with task handles is you stick them somewhere in a
data structure associated with the server thread ID and the object handles
you have for this server.  The handles themselves are pretty useless, you
only need them for the side effect of keeping the global task ID alive. 

The task server does not use task IDs internally to identify a task.  Just
as any other server, it will use pointers to the task data structure.

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

You will do it once when receiving such a handle to ensure it really belongs
to the task you received the thread ID for, but that is only to guard
against bugs - there is nothing you can do if you received the wrong handle
from your trusted source except to fail the operation (this will protect you
against leaking sensitive data to malicious tasks, so it is a good thing to
do).

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

That's true.
 
> A task handle will then have the form
> 
>   <task-server-thread, local-id, global-id>

No.  A task handle, as any handle, will have the form
<task-server-thread, local-id>

The point is that you never need the task ID after you have ensured that the
task handle represents the task you intend it to represent.  In the common
case the task handle will just be an associate to a thread ID, which
contains the task ID already.
 
> 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).

Well, sort of.  The task server to be used (more precisely, your own task
object) will be one of the initial object handles you receive at startup.

However, there is nothing wrong with using several task servers if you can,
so of course it's not redundant to keep the information in the handle
structure.

> A general object handle (in a client) will have the form
> 
>   <server-thread, local-object-id, server-task-handle>

That should be a server-task-id-handle.  However, I don't think that it
should be part of the object handle itself.  I would expect the object
client library to collect all objects provided by the same server in a
single data structure.  This is also important as you usually only want to
get one death notification for the server task.  (Note however that this
doesn't make server-side reference counting unnecessary).

So you have more something like
<server-task-id>
   <task-id-handle>
   <death-notification-info>
   <server-thread, local-id>
   <server-thread, local-id>
   <server-thread, local-id>
   <server-thread, local-id>
   <...further data like locks etc...>

(Note that the server-thread numbers can be different, in case one server
task provides several services).

You might want to further optimize that by collecting all local ids for the
same server-thread in a single list.  Not sure.  That is really an
implementation detail :)

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

Semantically, yes.  I am thinking along lines like this:

<client-task-id>
  <client-task-id-handle>
  <count>
    local-id-1:<server-object, references>
    local-id-2:<server-object, references>
    local-id-3:<server-object, references>
    local-id-4:<server-object, references>
    ...

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

Yes.  In a table form like the above, this is a trivial operation.

> To me there seems to be an essential difference between task handles
> and other object handles.

I observe that for a while now, and I still disagree.  The difference is
only in the actual implementation of the handle movement operations. 
However, note that the task server is not relieved from making the same
guarantees to itself as it makes to other tasks via task ID handles:  A task
server RPC must just as well make sure that between certain steps the target
task id is not reused as other servers, to ensure that the right task will
receive the reply, for example.  So where other tasks must acquire a
reference to a task ID handle, the task server itself can just acquire a
local reference to the task ID or some lock.

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

The object server implementation will implement the handle transactions,
which depend on the task server primitives.  That is the highest level where
this can be addressed.  With carefully written code it might be possible to
only require overriding a couple of functions or function pointers to make
this work.

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/