Re: Task destruction

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> I think all we need is tracking of the anonymous handle in task inheritance,
> and make changing the handle a privileged operation.

Agree, except that I suspect that we'd need a *list* of handles to
support multiple proc servers in a natural way. Each server that wants
to control a task (usually, that's only the proc server(s)) need to
install a handle. BTW, it seems that we also need a bigger list of
handles for other servers that have requested task death
notifications, so what we really need is a list of

  {
    struct { int target, int id } handle;
    enum { INHERIT=1, CONTROL=2 } type; /* flags */
  }

CONTROL implies the right to kill or otherwise manipulate the task.
INHERIT means that the handle is inherited at task creation. Proc
usually sets both flags.

As before, adding a handle with the CONTROL flag set can be done only
at task creation or if there's no control handle present, and
modifying a handle is allowed only by a task matching the current
target of that handle (usually the proc-server used by the responsible
process). I see no need for the notion of "privileged" process so far.

Does that make sense?

I think we also agree that not all tasks are processes. The question
on whether or not to assign pid:s to non-processes is a design
decision for proc, which I think is mostly independent of the task
server, so I'll leave that for now just noting that I agree it seems
convenient to have id:s for tasks in the same namespace as processes.

One question for the task server is whether or not operations such as
listing all tasks, requesting task creation notifications, or
examining the handle(s) associated with a task, needs to be a
privileged (or restricted in some other way). The answer is not quite
clear to me.

/Niels