Re: task death notifications

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> I was thinking about task death notifications, and noticed how hard it is to
> get them right on L4.  I don't remember a thorough discussion of them, I
> think Neal and me just took it for granted that it was straightforward.

The way I've been looking at this, each server will have to manage
all "port rights" for all "ports" the server receives messages on.
There will be a table that lists each thread (or task) that is allowed
to send messages to the port.

The primary operations that modifies this table, I think, are

  (i) when the server creates a new port right, and returns it as the
      result of an rpc. For instance, dir_lookup on a directory may
      return a port right to a file in that directory

  (ii) when the server, on the request of some client, transfers (or
       copies) a port right to a different task. The protocol for
       doing this have been discussed earlier (although I'm not sure
       if the perfect solution was found).

Now you are talking about a third operation,

  (iii) deleting a port right, and all associated resources, because
        the thread that held the port right has died.

I think the natural way to get the (iii)-type updates right, is to
request a thread death notification whenever a new port right is
*created* as the result of an operation of type (i) and (ii).

On Mach, we have "port death notifications" and "no senders
notifications". When servers manage their own port rights, it seems
these can be unified, the server needs to get "sender death
notifications" in some way or the other. When such a notification is
received, the sender count for the corresponding port can be
decremented, and when it reaches zero, a "no senders" event can
be generated internally in the server.

I'm afraid this gets simpler of all port rights are associated to
*threads*, not tasks, but I guess we'd rather not do that. And then it
seems thread death requires a different and more fine grained
notification than task death.

One way to solve it, assuming that we already have dealt with task
death, is as follows: whenever the server creates a new port right,
with a new task-entry in its table, it contacts the task server and
requests not only task death notification for the task, but
thread-death notifications too. Then the server gets notified on the
deaths of *all* threads in all its client tasks.

It seems one could easily get quite heavy traffic of thread-death
notification traffic. One could perhaps fix that by having the task
server send *batches* of thread death notifications, a little more
seldom. It shouldn't matter much if they are delayed a few dozen ms.
There may still be races, but perhaps it helps that the task server
can control both the batches and the reuse of thread id:s?

> 1. One way would be an interaction with the task server, that requires the
> client to copy a send right to a task identifying port to the server. 
> Because the server receives a (not privileged) handle for the task, the use
> of global ids for identification is reduced, and no misjudgement can
> happen.  The server can then use the "task id port" handle to request death
> notifications.  I have not really thought this scheme through, but it should
> work out, however, it is quite a complex setup and imposes some overhead on
> the communication between client and server.

Sounds like a reasonable way for the server to get notifications on
the death of particular threads in a client task. I think it would
make sense to set up this task port when the port right is created,
not per blocking rpc. And it could be optional, as it's needed only if
the server wants to offer blocking rpc services, *and* the cleint
intends to use them.

> 2. The other way is to make global thread ids more robust.  This means the
> task server has to make some sort of guarantee about not reusing global
> thread ids (with their version part taken into account, at least) for some
> time.

Sounds tricky to get right.

Regards,
/Niels