notifications

[Marcus Brinkmann]

At Thu, 07 Oct 2004 12:03:36 +0200,
Bas Wijnen <address@hidden> wrote:
> 
> [1  <text/plain; ISO-8859-1 (7bit)>]
> Marcus Brinkmann wrote:
> > There is something that needs to be said about task death
> > notifications.  Notifications in L4 are an impossibility for us.  It's
> > simply not possible to implement them robustly and securely.
> > Everywhere where we are saying notifications, we actually mean some
> > sort of polling mechanism (a dedicated thread in the client polling
> > for new events).
> 
> Actually, if it's a dedicated thread, then it should be possible:
> 1 - A calls an IPC to task, with infinite receive timeout.
> 2 - task notes that A is ready to receive a message.
> 3 - A sends (from a different thread) a notice to task that it wants to 
> be notified when B dies.
> 4 - Task records this.
> 5 - same for C.
> 6 - Task records this.
> 7 - B dies.
> 8 - Task sends a message about it to A.

Specifically, it replies to the IPC started in 1.

> 9 - C dies.
> 10- Task waits (and does _not_ notify A yet.)

Be precise.  We want to define what "notify" means, so you can't use
that term.  Better: It can not send a message to A because there is no
request to reply to.

> 11- A has handled the death of B and starts receiving again (using the 
> same system as in 1.)
> 12- Task sends a message about C's death to A.
> etc.

Well, this mechanism is exactly what I mean with polling mechanism,
and is for several reasons something quite different from what we
meant with "notifications" originally.  Note that you can also cancel
the IPC from 1 and let that thread handle the request for more
notifications in its next request (this makes things more
synchronous, and may be desirable or not).

> If task's death notification fails, then the receiving task is not 
> behaving correctly,

You mean if sending a reply message fails.  But that is generally true
for reply messages.

Well, you can devise protocols which can cope with lost messages (see
the console interface).  However, in this case, I already decided long
ago that task has to buffer task deaths until the "notification" is
received.  This is just a security requirement because of the global
thread IDs.

We still need some way to limit the number of task deaths you are
allowed to declare an interest in, to avoid DoS attacks.  But there is
no plausible scheme, maybe it's something better left to the
administrator.

> and may not expect anything (it may not receive any 
> notifications anymore, it will definately not receive the same death 
> notification again, it may be killed by task, anything can happen.)

Obviously.

Thanks,
Marcus