Re: new exec server protocol

[Niels Möller]

Now we're getting into the task-server...

Marcus Brinkmann <address@hidden> writes:

> On Thu, May 22, 2003 at 10:13:24AM +0200, Niels Möller wrote:
> In general, this can be accomplished with appropriate task server support.
> For example, the task server could internally create a new address space
> (thus a new task) as part of the task_revoke call.  In fact, a task server
> could not create any address space at all at the time of the task_create,
> but only fill in the accounting ID and allocate a task ID and create a
> handle for the task.

For now, I've been thinking that a "task" is an address space with at
least one thread. When the last thread dies, the task turns into a
zombie. When all references to the task is gone, it is deleted. Do we
have any use for "live" tasks with no threads in them?

> > And then it
> > requires a task port abstraction (the task server gets simpler if we
> > can get by without that: I'd prefer that the task server not know
> > about object handles, because it implements task references which is a
> > building block for handles).
> 
> Mmh, I am not sure we can do without a task port abstraction.  Well, maybe
> if you use the accounting ID for basic authentication and proc server special
> privileges for global authentication.

I think I've dropped the accounting id as autorization idea, at least
for now. The rules are

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

> In fact, even task ID references are special in that they are not
> normal object handles as they should be (which everyone could
> request). The reason that I suggest them not to be normal objects is
> purely an optimization: There is a need for every task to get such
> references to every other task it wants to communicate with. So
> there will be a lot of such objects. This can be implemented
> efficiently by just having a bit matrix.

Interesting trick. To have the reference counting decentralized to the
tasks them selves seems like it can save some storage in the task
server.

However, most references will also imply that death notifications
should be sent to the task. Either that thread id must be stored in
the taskserver for ich subscription, or we use some fixed mapping
between task id and death notification thread. Hmm, or we store it
with the task, and require the task to use the same thread for all
such notifications it wants. I think I like that.

[ BTW, how should notifications work in general? A server will send
  out notifications with a zero timeout, which may fail. A client must
  also be able to poll for the next notification. Note that delivery
  of death notifications must be reliable, but it's ok if they are
  delayed. ]

> >  * The old task should get the thread id of the new task, and a
> >    reference to it. This is the hard part, it seems.
> 
> Right, this is the main problem that pushed me in the direction of the
> pre-file_exec-task-creation which now has become a
> pre-file_exec-task-ID-reference-taking.  The main idea behind this is that
> you don't need to pass from fs to old task what already _is_ in the old
> task.

Hmm, what about this idea: Implement a task-server RPC where one task
(A, the old task, in the exec context) can say that a particular
other task (S, the file server) is allowed to give A one reference to
a task (B, the new task) of S's choice?

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

/Niels