local vs global object IDs

[Marcus Brinkmann]

Hi,

so far the assumption was to have global object IDs.  A handle would then
consist basically of a server thread ID and an object ID.  The access right
would be checked according to the senders task ID, encoded in the thread ID.

Local object IDs where considered shortly in a conversation between Neal
and me last year, but we went for global object IDs because, IIRC, it just
seemed simpler at that time.  Now being closer to an actual implementation,
I am starting to change my mind on this.

Note that it is simple to make the handle movement protocols work with local
IDs.  On receiving a handle you just have to pass the local ID in the reply
message.  Other details like initial task ID handles inserted into a task
etc are equally simple to solve (just return them in the task create RPC).

Note further that once you allow local IDs, their use is optional.  You can
just use global IDs for local IDs and everything will still work.  The other
way is not true: If you don't expect handles to be local to a task, you can
not use them.

For every RPC to an object, you have to find out if the sender has access
to the object.  For this, it is obviously an advantage if you have some sort
of index or other ID local to that task (as a user of the object)
that points you directly to the entry in the data structure (be it a data
structure associated with the object or with the task) that indicates that
this task has permission to access the object.

Mach port names already are local to a task, so we know how to deal with
them in the Hurd programs.  If a task already has a handle for the object,
the server will ensure that the same local ID is used if the task receives
another handle.

There are other reasons, mostly related to memory management, that lead me
to the impression that using a local ID can have an advantage over using a
global ID, while I don't see any particular case where using a global ID is
better than using a local ID (this was a bit contrary to my intuition, but
the solution is that you must perform an indirect lookup on the tasks access
rights anyway, and that can give you the object pointer without any extra
cost).

Note that this would also eliminate the problem of reusing object ids while
there are still tasks referring to it.  Instead the local ID entry for that
task and object can be set to denote a dead name.  In fact, using local IDs
would mean that we make one step in direction of the Mach IPC system
conceptually.  Coupled with clever memory management this can potentially
lead to a situation where all costs associated with a task's references to
objects, except the object itself (which might be shared anyway), are
directly attributed to the task.

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/