Notification server design

[Matthieu Lemerre]

Hi everybody,

We have talked a lot at LSM with Marcus and Neal, and below is a
mixture of a preliminary design of the notification server from
discussions I had with them and personal thoughts:

* The notification server may be separated from the cap server, so we
  do the separation. For instance, dead name notifications needn't be
  quick: a client can easily find out that the server destroyed his
  capability, just by sending a message and fails. Making all the
  notifications at once would put a lot of load on a machine: so the
  notifications should be given to the notification server with a low
  priority thread on the cap server.

* Each client can have a "notification capability" on the notification
  server. For each capability, the client would have to provide a
  container to the notification server (in which the server will store
  the pending notifications, dividing this container into slots).

* The client can then request "notifification id tokens" on a
  capability. This notification id token is an identifier for one slot
  in the notification table of the client. In this RPC, the client
  should map the send endpoint corresponding to where it wants to
  receive the notification. Surely it should also give the number of
  slots it want to associate with this token. Notifications could then
  be queued on this slot either using a round robin (so if we loose a
  notification, it is the oldest.) or dropping the latest if the queue
  is full.

* So the client may eventually loose some notifications, but this is
  not a problem: let's review the different kinds of notifications:

** Notifications issued by the cap server

There are two of them:

*** No sender notifications are given to the server when nobody longer
    use the ressource.

In order not to loose this notification, each time the server
provides a new object it must give a notification id token for one
notification to the cap server.

*** Dead name notifications are given to the client when the server
destroys the associated capability.

Similarly, for each accepted capability the client should give a
notification id token for one notification to the cap server.

A useful optimisation would be here to request several notification id
tokens to the cap server.

** Notifications "replacing" blocking syscalls like read or select
 issued by untrusted servers.

We can give to the server one notification slot per blocking call.

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

** Notifications for file and directory changes.

We can certainly loose this one (for instance, if there is a directory
copy, it's better not to receive all the notifications).

So, there is always a way not to loose the notifications we need.

Thanks,
Matthieu