l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new exec server protocol


From: Marcus Brinkmann
Subject: Re: new exec server protocol
Date: Thu, 22 May 2003 17:01:40 +0200
User-agent: Mutt/1.5.3i

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.

> > This makes the proc server mandatory, something that is otherwise
> > unnecessary.  I think a few weeks ago, I wanted to work without handles and
> > you assumed we would have them.  Maybe in a few more weeks we will actually
> > agree on this issue :)
> 
> 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. ;)
 
> > > Ok, this is almost a handle, but a little more light weight and
> > > specialized than a real task port. A gives this right to S before
> > > invoking s:file_exec. S uses this right to insert the reference into
> > > A, before replying to the file_exec. When A has the reply, it asks the
> > > task server what reference it got (at at the same time unconditionally
> > > revokes the right).
> > 
> > Mmh.  This is interesting.  In general, this means that the recipient of a
> > handle must give notice that it accepts the handle before it is
> > sent.
> 
> The basic problem with this approach, is that if you want to let A
> have several such outstanding requests at the same time, the task
> server needs more state. For exec, that's no real problem: If several
> threads of A tries to call exec at about the same time, we can let the
> second one fail. The needed task server state is only two more words
> in the task structure.

Again, I think that just using normal handles is the answer to the question.

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]