Re: thread ids, task ids and subsystems

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> On Mon, Apr 07, 2003 at 05:20:06PM +0200, Niels Möller wrote:
> > My mental model is that unregistered tasks always "belong" to some
> > process (by the automatic inheritance of the "accounting id" in the
> > task server). When a process dies, all unregistered tasks belonging to
> > it will be automatically killed as well (by a single call to the task
> > server). Then the proc server doesn't need to know anything about the
> > individual unregistered tasks, just like it doesn't need to know about
> > individual threads.
> 
> That is an interesting idea, although I think you still would want to be
> able to see each tasks individual information (as much as is available,
> which is usually not much, but could include information like run time and
> memory usage even if the task is not registered), and be able to kill them
> individually (and debug them!).

For a start, memory and cpu usage should be included in the counts for
the process that the task "belongs to". That's enough to detect and
start locating run-away tasks, and killing the corresponding process
should be a working, although brutal, way of stopping an offending
task. Just like you usually kill an entire process if one of its
threads starts sucking 100% cpu.

To examine or kill individual taks, one needs some utility (be it ps
or some different program) that talks to the task server, not just to
proc.

Debugging is interesting, one would definitely want to be able to
attach gdb to a task. I don't have much clue about what gdb needs in
order to control a target, but it seems that there should be some
interface for that that will belong to the task server.

The access rule should probably be that one is allowed to debug a task
if and only if one is allowed to debug the process which the task
belongs to. Which really is proc's decision, so I guess one needs some
cooperation between proc and task (task shouldn't know about the
ideosyncracies of unix process persona).

Hmm, perhaps the simplest way of sorting it out is to have a
list_tasks call in task (I'm assuming anybody is allowed to list
tasks), but make the calls to kill a task or create a "debug port" to
it privileged in task, with corresponding calls in proc that do the
access control thing and then passes messages on to the task server.

Regards,
/Niels