Re: keeping track of thread ids

[Niels Möller]

Daniel Wagner <address@hidden> writes:

> After thinking a bit more on this the matter resolved into following:
> 
> 1. The root task has to create the threads

We need a task-server. This is either a few threads inside the
root-server address space, or threads in a separate address space
(which then has to use some root server thread as a proxy for actual
L4_ThreadControl and L4_SpaceControl system calls).

> 2. If task decide to die, it has to ask the root task for deletion
>    (ThreadControl)   

Or more precisely, it has to ask the task server.

Thread id:s will be of the form

    | subsystem |   tid | taskid |
      31     29   28 14   13   0
  
  The three bit subsystem identifies the Hurd subsystem, the task server
  will not accept any requests from threads in different subsystems. The
  subsystem and tid together form the L4 _threadno_.

So the task id is stored in the bits L4 calls the thread version number.
The task server will have to keep track of at least

  * Task id:s (and threads of each task).

  * Task handles. A task handle is either a "reference", which just
    prevents the reuse of the task id, and allows some non-destructive
    operations on the task, or a "control handle", which provides full
    control over a task. (All other "handles" in the system will
    consist of a reference handle to a task, a thread id, and an
    object id, where the task reference handle is essential for
    preventing gratious task id (or thread id) reuse).

  * State needed for the transfer of a task handle (of either kind)
    from one task to another. I think Marcus call these objects
    "transaction records".

  * Subscriptions for death notifications. Task A can request to be
    notified by the task server whenever some other task B dies. When
    A is notified, it is expected to mark all handles to objects
    served by B, and then destroy the B task handle. When all handles
    to B are destroyed, B's task id can safely be reused.

  * Accounting id:s. An accounting id can be thought of as a handle to
    a *group* of tasks, with the property that all new tasks that are
    spawned by the group will belong to the group. The task server
    allows the owner of this kind of handle to reliably kill all the
    tasks in the group. Perhaps cpu limits and the like can also be
    associated to these groups, but that's hand-waving on my part.

Regards,
/Niels