Re: reuse of task IDs

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> Seriously, zombie dust is what becomes of a zombie when it isn't
> allowed to leave.  Consider that every task in the system can register that it
> is interested in the fate of any other task.  It could receive death
> notifications for this task, but the task server would also make another
> guarantee: A task id will not be reused if there are still tasks
> interested in that task id.

You can formulate this as the task-death protocol: When a task dies,
the task server sends a message to all interested parties. The
receiver of the notification is expected to clean up all its state
related to the dead task (or mark the state as invalid, so that it can
be cleaned up later). When done, the receiver is expected to reply to
the task server. The reply means that the task is no longer interested
in the dead task. When the task server has received replies from all
the parties, it can go on and clean up *its* internal state related to
the task, and make the task id available for reuse.

If you think about it this way, it looks very much like a
syncronization operation, which seems to be what was needed.

You could keep some zombie state around during the protocol. For
example, a task that receives a death notification might send a "get
cpu usage" rpc to the task server. Then it must do that *before*
replying to the death notification message. The process server might
want to do exactly this, in order to construct the state for a posix
zombie. 

Looks nice and clean to me.

Regards,
/Niels