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 16:29:20 +0200
User-agent: Mutt/1.5.3i

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

I have to correct myself.  If you read my previous mail carefully, the
bitmask grows quadratic, while the average case might only scale linearly. 
So although there is an upper limit anyway (2^14 - 2^8 tasks), and the
absolute values are as I gave them in my mail, doing it either way is not
too bad I guess, in particular if the task ID reference data is small
compared to the other data we have to store about a 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).

What you describe here is not a handle send operation, but a handle receive
operation, where the sender declares the intent of receiving a handle, gets
a transaction record for it, sends the transaction record to the fs server
and the fs server can use the transaction record to return a handle without
blocking.  That's not bad, it's a good generalization.

However, I still like my idea of having old task create the new task better
for these reasons: first, puts the responsibility of providing the resources
to the caller.  Note that I have a strong tendency to move everything out of
servers and put it into clients where possible.  We should avoid spending
CPU cycles and memory in the server if they can be spent in the client
instead.  And a specialization of this is the accounting: In your model,
there is still a race where the accounting ID is wrong and SIGKILL doesn't
do what you want.

I think you provided a working model for the task ID reference back-passing,
though.  But I am tending towards using real object handles for tasks and
task ID references now rather than having special code for that in the
server and clients.

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]