Re: Comments on the hurd-on-l4 document

[Marcus Brinkmann]

At Thu, 9 Jun 2005 00:00:32 +0200,
"Yoshinori K. Okuji" <address@hidden> wrote:
> 
> On Wednesday 08 June 2005 22:38, Marcus Brinkmann wrote:
> >   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.
> 
> I don't see why you distinguish POSIX signals from notifications. For 
> example, 
> select() can be implemented on the top of POSIX realtime signals.

I seriously doubt you can implement select() on top of POSIX realtime
signals in the Hurd.  Signals are sent directly from process to
process, and the server will _not_ trust the client enough to send it
a signal, which really just means to send an RPC to its message port.
Also, the server may not even be authorized to send such a signal.

POSIX signals have very specific semantics.  When I talk about
"notifications", I refer to other very specific semantics, which are
different.  Well, both are ways to transmit information about
"asynchronous" events, but that's where it ends.

> Another example is SIGWINCH. To be able to obtain SIGWINCH, a task which 
> wants 
> to receive this signal shall negotiate with a terminal task, giving a 
> capability to this terminal task. For me, this looks identical to the 
> notification system you describe.

This is actually a good example.  I think that the right thing to do
here may be to give the terminal task a real notification capability
and then trigger the SIGWINCH locally, rather than have the terminal
task send a signal message to the task's message port.  This is
because the terminal task usually is a system service which doesn't
trust the user task and doesn't want to do a direct RPC.  (Or the
terminal task may be a user task and there is some lower layer at
which this notification happens).

Bottom line is that "signals" in the Hurd are usually direct RPCs to
the tasks message port, which we can't use for server-to-client
notifications, and notifications need a different mechanism with
different authentication etc.  So while some signals may still be
implemented as such direct messages, for some signals the actual
implementation may need to be a notification.

But on the other hand, you can not use notifications for all signals,
as notifications must be granted by the receiving task before-hand,
and thus the receiving task must first make some calls to the sending
task.  This would only be possible with the help of a third party like
proc, but we don't want proc to authenticate signals, we want to do it
locally in the task itself.

Thanks,
Marcus