Re: Signals, messages and exceptions

[Igor Khavkine]

On Sat, Jul 07, 2001 at 09:04:56PM -0400, Roland McGrath wrote:
> > Yes, that is what I was getting at. Signals and interrupts are
> > a very old concept, and I've always thought that exceptions are
> > a more evolved version of the same concept. So it would make
> > sense to use a more versatile feature to implement a less versatile
> > one, if they are of similar nature.
> 
> Uh, you are pretty lost in the vague here. :-) You'll do better with me if
> you just talk about specific technical parallels and what precisely it
> would look like if it were different.
>
> > You suggested, that I was confused about the purpose of exceptions
> > in Mach. Maybe I am, what is your take on this topic?
> 
> The purpose of the microkernel is to provide interfaces to the basic
> functions of the machine.  In Mach, most (nearly all) interfaces are in the
> form of some kind of RPC.  The exception_raise RPC is the kernel's
> interface for delivering machine traps.

Weren't signals designed to do the same thing at the beginning?
(SIGHUP, SIGFPE, SIGSEGV, SIGILL all correspond to machine interrupts.)
UNIX type signals are very few in number (only 32) and can only
be sent to a process, which back in the old days was the basic
unit of execution. Nowadays we have threads, and Mach's exceptions
perform the same task as signals were intended to. But exceptions
are handled on a per thread (or per taks) basis and allow a much
wider range of messages by specifying exception type (including
EXC_SOFTWARE for software generated exceptions), code and subcode.
The pthreads library allows for per-thread signals with
`pthread_kill()', so this can be handled in a uniform fashion.

I'm still not on very strong footing here. But here's what I think
is happening now when a process receives a signal is:

+--------+  kill()    RPC call   | +---------------+     +-------+
| proc1  | --------> ----------> | | handle signal | --> | proc2 |
+--------+                       | +---------------+     +-------+
                                 |       ^
+--------+    exception RPC      | +-----|-----+
| kernel | --------------------> | | translate |
+--------+  (from hardware)      | | to signo  |
                                 | +-----------+

This way there are two different ways that signals can arise, and they
are treated differently until the very end. And this way the exception
mechanism becomes unusable for anything other then sending signals.

The scheme that I'm thinking of would look more like this:

+--------+  exception_raise()     |
| proc1  | ------------------+    | +-------------+  yes   +--------+
+--------+                   |    | | corresponds | -----> | handle |
                             +--> | | to signal ? |        | signal |
+--------+    exception RPC  |    | +-----|-------+        +-----|--+
| kernel | ------------------+    |    no |     +--------+       v
+--------+  (from hardware)       |       +---> | custom |    +-------+
                                  |             | handle | -> | proc2 |
                                  |             +--------+    +-------+

As you can see, both approaches result in one system call to
convey the message to the target process. But in the second
scheme unifies the two ways that signals can arise (as I think
they should be) and also opens up the exception mechanism
to the application, if UNIX type signals do not provide
enough versatility.

When I look through code, I not only want to know how it works, but
also why it was designed a certain way. This is why these questions
came up when I was reading the Hurd signal handling code. Has the
second approach been considered during the initial design stage
and simply thrown away for valid reasons, or has it just not come up?

Igor