Re: emulating no-senders notifications in L4?

[Niels Möller]

Jean Wolter <jean.wolter@inf.tu-dresden.de> writes:

> If I understand your "reasoning" right you need the extra level of
> indirection to implement a reliable "no sender notification" for the
> case, that
> 
> - a task does suicide
> - a task dies violently (with this I assume you mean it raises
>   an exception  and is killed by the micro kernel).

Right.

> As Volkmar already pointed out it is impossible for a task to do
> suicide since only the task server is allowed to create and delete
> tasks. 
> 
> And a task can not die violently since if it raises an exception this
> exception is delivered to an exception handler thread which can handle
> this situation.

Is this thread running inside the task in question or in some other
task? 

> So it should be possible to inform all interested servers about the
> death of a task and therefore all server could clean up their
> resources if the dying task was the last user.

AFACS, this is a good way to make reliable task-death noticifications
work, but by itself it isn't enough for reliable port-senders
notifications unless. At the point when the tasks dies, it's data may
be FUBAR, so the only information about the task that is *reliably*
available is its id and the fact that it's dead. How do you know what
port-rights it had?

I'll try to sum up my reasoning, to let you point out where it is
wrong. There are two "devil's advicate" scenarios.

First, consider a task that owns a few send-rights. Then it
(intentionally or accidentaly) overwrites all its information about
those rights. And then the task dies (it doesn't really matter how it
achieves death).

In order for this situation to be cleaned up properly, including the
sending of appropriate no-senders notifications, the information
about the send rights must be registered by some trusted entity
outside of the task.

So lets assume we have this trusted send-right registry. Now consider
a task that doesn't keep the information up to date; it may receive a
send right from somewhere, and not register it. Or it may tell the
registry server that it has destroyed the send right, without
destroying it.

To make this work right, one must ensure that a send right that isn't
properly registered cannot be used. Sending all rpc:s through the
trusted port-rights server, i.e. adding a level of indirection, is one
way to achieve this.

Okuji's idea of mapping the table read-only into all tasks is another
way, but it can't handle all rpc (in particular, rpc:s that imply a
transfer of port-rights, although by my own reasoning it's fine if
those rpc take a different and more costly way), so for now I'm
thinking about it as an optimization of the rpc indirection.

Summary: The central book-keeping entity is indeed necessary. Whether
or not all rpc:s should actully be routed *through* that entity is an
open question.

...

When thinking some more, I realize that you can perhaps distribute the
"central" registry, giving the owner of each receive right the
reponsibility to keep track of all corresponding the send rights. Is
that what you're thinking of? Nice idea. A few potential drawbacks is
that

1. Transfer of port-rights gets more complicated. In particular the
   transfer of receive rights becomes more difficult. Does the hurd
   ever need transfer of receive rights?

2. You get a lot more parties that are interested in task death
   events. The task server to keep track of all subscriptions. 

A side effect is that the receiver gets the power to unilaterally
revoke any send right of its choice. This may be natural, but I'm not
sure the receiver has that power in Mach. So far, I've been thinking
of delegation (i.e. transfer of send rights) as something that is
under complete control of whoever wants to give a way a right, and
that the receiver should not care (or even know) that delegation has
taken place. That information hiding is possible with the central
port-rights server, but not in the distributed model.

Best regards,
/Niels