Re: Comments on the hurd-on-l4 document

[Marcus Brinkmann]

At 08 Jun 2005 20:24:33 +0200,
Niels Möller wrote:
> I think the notification server at least is fairly simple (although it
> will be on the communication path, adding overhead). What about this
> minimalistic notification protocol, somewhat inspired by amigaos
> "signals" (which are quite different from unix signals):

What you describe is pretty much what I came up with, too, with some
extensions:

* I was considering to let the caller hand out memory to the
  notification server where the notifications can be stored.  IE, the
  user must provide the memory resources via containers.  If the user
  revokes the memory, it loses the notifications, tough.

* I was considering to not use one bit for notifications, but just a
  bit more data.  As the user provides the memory, that should be OK,
  and allows us to return much more information from the server to the
  client.  Ideally the whole result of the operation.  There should be
  a fixed upper limit though, so it can still be organized as a table.

  Something like 4 or even 8 machine words per table entry should be
  plenty.

You write:

>  It's tempting to let the task that raises a signal include one or a
>  few data words to be delivered together with the signal. This might
>  be useful, only complication is what should happen if there are
>  several attempts to raise a signal before it is handled. We don't
>  want to queue the corresponding data words, so either data has to be
>  discarded, or the raise rpc can return an error code if the signal is
>  already active.

  But we are not talking about signals, but about notifications, and
  each notification stands by its own.  To get another notification,
  the server needs another capability (or one capability good for two
  notifications).

  This means that notifications never can "just happen".  They have to
  be anticipated by the client, and the client needs to provide the
  necessary capabilities.

  BTW, I didn't think much about POSIX signals.  I think that signals
  will still be done by sending messages directly to the tasks message
  port, not via notifications.

* This can then also be used for more than one notification, for
  example for file notification changes, which include the type of the
  change and the start and end offset within the file.

  For this, it makes sense to optimize and allow the client to create
  capabilities which allow to send more than one notification to the
  client.  In general, N notifications, where N is a fixed number
  smaller than the total the client has given memory for.

* Neal disagreed with me, and said that this would lead to a lot of
  wasted memory, and that instead something fancier should be done
  with the memory allocation stuff.  I am game for that.  How the
  memory is managed will make a huge difference in performance, but
  doesn't change much about how notifications work in general.  As
  long as we can make the right guarantees, it doesn't matter.  What
  is important is that a server can make an RPC to a trusted
  notification server and stop worrying about it.

Your PS:

>  Including a data word could be useful for example in case of select
>  on a large number of files served by a smaller number of servers.
>  Then one could use a single signal per server, and let the server
>  include the object id of some file with the notification. But this
>  assumes that the client can know which server serves which object,
>  which may not be the case.

This is partly true.  The client doesn't know which server implements
the objects, but the server does!  So, one way to do this would be to
make an RPC to a server with as many objects as fit into a single
message (won't be many anyway as objcets are typed data and there are
only 64 message words).  Then the server can return a bitmap of
objects it knows and doesn't know, and the client can filter them
accordingly.

OK.  This isn't really great.  If you have 1000s of sockets, this will
blow.  We knew before that select blows, and the new cap system will
make it considerably worse.  Many people will say that the real
problem is select(), though ;)

Thanks,
Marcus