Re: Task destruction

[Wolfgang Jährling]

Niels Möller <address@hidden> wrote:
> 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. 

I currently fail to see how the system administrator will have control
over every task (or process) in your design.  And I think it is very
complex.  Other than that, it looks fine.

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

Why?

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

Yes, exactly.

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

That all tasks are known to the systems main proc server does not mean
anyone has to talk to this server.  You can savely ignore him
completely, just as it is the case on Mach now.  But he will know about
you, so that the system administrator can kill you (as is the case on
Mach now).

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 ]