Re: Task destruction

[Niels Möller]

Wolfgang Jährling <address@hidden> writes:

> Every task can be destroyed by
> a) itself
> b) the systems main proc server
> c) in the case of a Neighbourhurd, another proc server
> 
> My question is, has anyone thought about how to achieve this?  If not, I
> am willing to give the various alternatives some thought and propose a
> scheme for this.

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

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

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.

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?

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.

Does this make sense?

Regards,
/Niels