Re: Task destruction

[Wolfgang Jährling]

Niels Möller <address@hidden> wrote:
> One issue that has been discussed earlier is that all tasks, even ones
> that haven't registered with any proc server, need some kind of
> owner/identity.

Sure, that's a task-id.

> The identity could be of the form <proc-server, process-id> for the
> closest ancestor that is (or was) associated with some proc server.

Except for that we want more something like an association
<master's-task-id,task-id>, where the master is permitted to kill the
task "task-id", I agree.  I have not given it too much thought, but my
idea was to add an argument to the task_create RPC to specify the
master.  The task-server would notify this "master" about creation and
death of the task.  Additionally, we could define that the first master
that is ever registered this way gets notified about creation and death
of all tasks and is permitted to destroy every task.  (Obviously I am
speaking about the systems main proc server here.)

When creating a new task, we would usually specify our own proc server
as the "master" (i.e. the task we will get from getproc (), which I just
assume we will, as an object handle alone is never enough).

> One important responsibility of the task server ought to be to
> maintain that identity so that it is reliably inherited when new tasks
> are created.

Do we have a reason to use inheritance here?

> Another is to deal with resource usage information and
> limits for such tasks. (This is on the assumption that the process
> server wants to deal only with tasks that register with it
> voluntarily, but I guess there are several ways to divide the work
> between the task server and the proc server).

I am not sure what you mean.

> If we have a process P that has spawned, directly or indirectly, a
> task T that is not associated with any proc server, I think it makes
> sense, when it comes to resource limits and license to kill, to treat
> T in a similar way as a thread within P.

I assume that with "associated", you mean "registered"?

> The identity of T is really a reference to P, and if one goes this
> way, the proc server (which is the authority on P) needs to keep some
> information around if P dies before T. Or perhaps T should be killed
> immediately, with no mercy, whenever P dies?

Care to explain why you think it makes sense to treat T similar to a
thread in P?  And what we do in the case of P dieing early could be left
up to the proc server, where I would prefer the default value not to be
killing.

> In the case of neigbour hurds, I think it makes sense to deal with the
> entire neighbour hurd, including all its tasks, as associated with a
> single process in the parent hurd, namely boot. This implies that a
> task may need several identities or associateions: A task in the
> neighbour hurd needs to be associated with both some process in the
> neighbour hurd's proc server, and with the proc server and the boot
> process in the parent hurd.

Depends on what kind of "association" you are speaking about.

Cheers,
GNU/Wolfgang

-- 
Wolfgang Jährling  <address@hidden>  \\  http://stdio.cjb.net/
Debian GNU/Hurd user && Debian GNU/Linux user \\  http://www.gnu.org/
The Hurd Hacking Guide: http://www.gnu.org/software/hurd/hacking-guide/
["We're way ahead of you here. The Hurd has always been on the    ]
[ cutting edge of not being good for anything." -- Roland McGrath ]