Re: new exec server protocol

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> On Thu, May 22, 2003 at 03:49:01PM +0200, Niels Möller wrote:
> > Do we have any use for "live" tasks with no threads in them?
> 
> Well, I proposed such a use, of course.

The "half-created" task is simple to do, I guess (except to implement
task ports). That would make the lifetime of a task be

  * embryonic (recorded in the task server, but no corresponding l4
    objects.

  * alive (one or more threads)

  * zombie (no threads)

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"?

> >   * Any thread in a task can manipulate the task itself.
> > 
> >   * The privileged task can manipulate any task.
> > 
> >   * For any other manipulation, a task has to cooperate with a
> >     privileged task (i.e. proc). Proc can request things like "kill
> >     everyone with accounting id x".
> 
> 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.

We'll see.

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

/Niels