Real processors often use the same mechanism to handle exceptions and interrupts. However, since exceptions are usually caused by a processor trying to execute an erroneous instruction, it makes no sense for an operating system to package an exception as a message to the process, and then to allow the virtual processor to carry on executing until the process explicitly accepts the message.
Clearly, after an exception, the virtual processor must suspend the execution of the instruction stream that caused the problem, and either carry on with a different instruction stream, or have the process terminated. The mechanism for doing this should preferably involve minimal overhead for the ordinary process, which should not generate exceptions and should be terminated when it does. The mechanism should also be machine independent so as not to decrease portability, and should provide the programmer or language run-time system with complete control over what happens when an exception is generated.
The simplest mechanism that will do the job is as follows: When a process generates an exception, it is suspended, and the event is packaged into a message that is sent to its parent process. The parent of a process can then cause its suspended subprocess to be restarted at any point within the subprocess address space. Alternatively, the parent can simply terminate the subprocess.
This mechanism allows the operating system to handle exceptions using a simple non-interrupting scheme that exacts no overhead other than the cost of sending a message (the minimum cost in a non-shared memory multi-processor). The policy decisions on what to do about an exception are relegated to a machine-independent protocol between the process and its parent process. Moreover, the mechanism provides the programmer and/or language run-time system with complete control over what happens when a process generates an exception.
