Re: new exec server protocol

[Marcus Brinkmann]

On Thu, May 22, 2003 at 07:06:38PM +0200, Niels Möller wrote:
> Marcus Brinkmann <address@hidden> writes:
> 
> > On Thu, May 22, 2003 at 04:40:18PM +0200, Niels Möller wrote:
> > > To me it seems to make things simpler to always have death of the last
> > > thread imply death of the task. So let me rephrase the questions as
> > > "do we have any use for tasks that are in the alive-state, but have no
> > > threads"?
> > 
> > Not sure.  Do we want to disallow this?  It is simple to keep an inactive
> > thread around in a task, although it has a slightly stupid touch.
> 
> It just seems pointless. And if a task happens to have all its threads
> call thread_suicide, who's going to change the task to either the
> running or the dead state?

I don't know if it is pointless.  I also don't know if the last
thread_destroy should really imply a task_destroy.  I don't have the
complete picture about the requirements of the task server (for example,
without any expectation on my part, my views changed radically as soon as I
looked at exec.  Who knows what else awaits us?).  Anyway, why do you want
to determine this right now?

As about who might create new threads: Of course someone owning a task
handle.

> > > My preferred generalization is to to replace accounting id:s with
> > > lists <ownser, id>. Then proc is privileged with respect to tasks with
> > > accounting id <proc, x>, but any other task A can attach entries <A,
> > > x> to tasks it creates, and be privileged with respect to those tasks.
> > 
> > These are already handles.  I think you are reinventing the wheel. ;)
> 
> Right, they're handles to collections of tasks.
> 
> Still, I think I'll go on hacking with raw, handmade "handles" until I
> have some more experience, and somebody writes up libport.

I certainly don't want to stop you from hacking.  But I can not answer
arbitrary questions that need to be answered when coding things like the
task server before I have a more complete understanding about the design
constraints.

In other words, if you want to write any task server just for the thrill and
learning effect, that's fine.  If you want to write the Hurd task server,
then I think it is too early for that.  Not way too early, but there are a
couple of important things required before the task server is even useful to
have.  I'd rather proceed with things in order than discussing questions
like what happens if the last thread in a task is destroyed now.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/