Re: reuse of task IDs

[Marcus Brinkmann]

On Mon, May 05, 2003 at 08:40:53PM +0200, Niels Möller wrote:
> 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.

This is correct, you can conveniently put it that way.  However, I am not
sure that this would be the final form, just because we need notifications
for other things as well, and notifications themselves should not be tied to
replies (notifications in general don't have synchronization requirements at
the server side).  The reason I kept it separate is that notifications are
a separate abstract concept in my head.  You might also want to allow
references without notifications or notifications without holding a
reference.

However, the constraints and consequences are absolutely identical for what
we are talking about.

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

Ah right, at least for privileged processes (proc server!) that is certainly
interesting.  It would be nice if that blends into it.
 
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/