Re: Task destruction

[Niels Möller]

Wolfgang Jährling <address@hidden> writes:

> I don't think the task-server should know anything about the concept of
> processes at all, as we want it to be possible to implement a completely
> different kind of task-management.  This is the reason why I am aiming
> at very primitive basic operations.

If the task server follows the outline in my previous mail, it doesn't
need to know any details about processes. It only needs to associate
handles to tasks, make sure they are inherited, and follow some simply
rules on modification to the handles. It will never send any messages
to the handles (except for general book-keeping messages needed for
handle transfers, etc).

> Does "the proc server" refer to the systems main proc server?  If not,
> how do you find out who is a proc server and who isn't?

I think we can get away without the task server knowing what is the
"main" proc server. Comment my outline mail if you see any flaws in
it. 

> > Now it sounds like the proc server will need to know about every task.
> 
> That the systems main proc server knows about every task was my
> intention.  This is also what we currently have on Mach.  I never
> thought about whether this is actually good.

In the multiple-hurd case, that means that a process can get two pids,
one with the main proc server, and one with the proc server in the
hurd in which the task wants to live. That's not outrageous, but it
may be nice with some lighter association.

> > The two ends of the scale are:
> > 
> > A. The proc server knows only tasks that has registered
> >    with it voluntarily. Information about other tasks must be somebody
> >    else's responsibility (e.g. the task server's).
> > 
> > B. All tasks are known to some proc server. In this case, we could
> >    assign a pid to each and every task in the system. Then there's
> >    very little left to do for the task server.
> 
> I feel that B is more like what we want, because we should try to keep
> functionality outside of the task-server, as users can't easiely replace
> it.

As I understand you, you are thinking about a somewhat stronger
variant of B: All tasks are known to the system's *main* proc server.

>From the point of view of a user that wants to use his own hurd and
his own proc server, there's no huge difference if system book-keeping
is done by the task server or by the "main" proc-server: neither can
be replaced by an ordinary user. But it seems nicer to not have to
talk to the main proc server at all, and put the things that really
are essential for cooperation between the user's own hurd and the rest
of the system in the task server. To me, the focus of proc is posixish
things, and that makes it look as the wrong place for this.

I'm thinking of the task server as a server providing essential system
services to any proc-servers running on the system, and also
potentially to other operating systems running on L4, maybe even at
the same time. In this way, the role of the task server is similar to
that of the memory managment server.

> I'd rather say it would be a convenient way to kill a single task,
> as I assume tasks will usually be independent, so why kill them all
> together?

That's probably right, *if* all tasks are processes, so that they all
have separate pids, can be viewed with ps, etc. For tasks that aren't
processes, I think it is desirable that they have some responsible
process, and if they get out of hand, you can get rid of them by
killing the responsible process.

/Niels