[Top][All Lists]
[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/
- Re: new exec server protocol, (continued)
- Re: new exec server protocol, Niels Möller, 2003/05/21
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/21
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/21
- Re: new exec server protocol, Niels Möller, 2003/05/21
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/21
- Re: new exec server protocol, Niels Möller, 2003/05/22
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/22
- Re: new exec server protocol, Niels Möller, 2003/05/22
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/22
- Re: new exec server protocol, Niels Möller, 2003/05/22
- Re: new exec server protocol,
Marcus Brinkmann <=
- Re: new exec server protocol, Niels Möller, 2003/05/22
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/22
- Re: new exec server protocol, Niels Möller, 2003/05/22
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/22
- Re: new exec server protocol, Marcus Brinkmann, 2003/05/22