Re: Comments on the hurd-on-l4 document

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> The notification part of the server would be comparatively heavy,
> but the reference counting itself should be moderately light-weight.

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):

Each task can allocate (a large number of) of "signals" by rpc to the
notification server. A signal is identified by an integer.

The notification server conceptually holds a table for each task, with
one bit for each allocated signal, saying if the signal is active.

A task can hand out the capability to set a particular signalling bit
("raising the signal"). If the bit is already set, nothing happens. If
several bits are set, there's no strict ordering between the bits.

The task notification thread repeatedly calls the notification server
rpc "give me the next (or the next few) active signals". This blocks
until at least one bit is set. When this is the case, the bit is
cleared, and the corresponding id is returned. The thread will lookup
and invoke the "handler" for this signal. Typical action will be to
wake up some other thread via condition variable or local ipc,
whatever.

To request notifications from some server, one needs to

* allocate a new signal id for this notification,

* install a handler for one's own notification thread,

* give the server a capability to raise the signal, and instructions
  on under what conditions it should be raised.

So I think notifications are an easy problem if we accept a central
server, and have working capabilities.

Regards,
/Niels

PS:

 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.

 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.

 So it seems the pure way of keeping only a single bit of state per
 signal is good enough.