Re: Notification server design

[Marcus Brinkmann]

Hi,

just a few notes:

At Tue, 12 Jul 2005 19:42:38 +0200,
Matthieu Lemerre <address@hidden> wrote:
> *** Dead name notifications are given to the client when the server
> destroys the associated capability.

Needed for:

* Clients doing RPCs: They need to break out of pending RPCs on a
  capability if the underlying object gets destroyed and they are
  blocking in the receive phase.

* Servers running continuations: Each continuation is associated with
  a notification capability provided by the client.  If the
  notification capability gets destroyed, the server needs to abort
  the operation and destroy the continuation object.

  (Note to self: This would not be necessary of course if the server
  would keep all information about the continuation on user provided
  resources.  Hard to do though)

> ** Notifications for events like POSIX signals
> 
> POSIX does not guarantee that signals are queued if they're not
> processed in time. So we can just use one notification slot per POSIX
> signal we want to receive. But we must not use a round robin here, and
> just drop the newest messages.

POSIX signals in the Hurd are right now implemented as calls to the
task's message capability.  I currently don't see a need to change
that.  Notifications don't need to be used for that.

The advantage is that the task can authenticate the signal itself.
Or, to put it another way round: The task posting the signal needs to
get the notification capability first if it wants to do so.  Where
could it get the notification capability from?  The answer is right
now: From the receiving task itself.  In this case, it makes no sense
to separate it into two calls.

Thanks,
Marcus