Re: new exec server protocol

[Marcus Brinkmann]

On Thu, May 22, 2003 at 03:49:01PM +0200, Niels Möller wrote:
> 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?

Well, I proposed such a use, of course.  The requirement to have at least
one thread in the address space is an L4 requirement.  Of course we need to
keep at least one thread around to not destroy the mappings if we still need
the address space after all threads died.  However, _before_ the first
thread exists and runs there is no way to have any mappings (you can not
"insert" mappings into a task), so it's clear to me that we can delay the
actual creation of the address space until the first thread is created.
 
> 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".

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

I refuse to nail this down until I have a clear picture on the open issues
like how to do an exec and how to do the various forms of IPC we need.
For my solution to the exec I need task handles, and it's always better to
use one concept instead two if there isn't a strong reason not to.
 
> > 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.

Ah, I knew I forgot something.  Well, you are right that might mean the
bitmask is not as useful as I thought it to be.  I have not yet come to a
conclusion about this, I just know about the requirements I have for task
IDs and references to them.  The bitmask was just an idea for a good
optimization.  If we conclude we don't need that, then we can also use real
handles that we bind the notifications to.

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

I simply don't know yet.  Notifications are always a pain, and polling sucks
even more.

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

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.  This
could also be used in the generic handle movement transfer, except that it
requires more RPCs.  I will think about it.  I don't like it as a special
solution for tasks, but maybe this even works better than what we have now
for all handle movements.

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/