[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on the hurd-on-l4 document
Re: Comments on the hurd-on-l4 document
Wed, 08 Jun 2005 22:38:04 +0200
Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)
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
* 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
> 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
This means that notifications never can "just happen". They have to
be anticipated by the client, and the client needs to provide the
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.
> 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
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 ;)
Re: Comments on the hurd-on-l4 document, Marcus Brinkmann, 2005/06/08