TITLE: why no exceptions from signal handlers

PROBLEM: thp@cs.ucr.edu (Tom Payne)

Implicit in a qestion of what the Standard says are the related
questions of what it should say and why --- why shouldn't signal
handlers be allowed to throw exceptions?  (The question seems both
interesting and appropriate.)


RESPONSE: clamage@Eng.Sun.COM (Steve Clamage), 16 Jan 96

Exceptions are synchronous, and unwind the stack from the point of the 
throw to the point of the handler. When an asynchronous signal arrives,
what is the state of the stack? Answer: unknown. In particular, the
stack might not even be in a consistent state -- arguments half pushed
during function entry or half popped during exit.

In C, a signal handler isn't allowed to do much of anything, precisely
because the program state can't be known and may be inconsistent. The
same is true in C++.

Allowing exceptions to be thrown from a signal handler would place a
noticeable penalty on all programs to provide locks on every function
entry and exit, even programs that didn't throw exceptions or use
signals.


RESPONSE: clamage@Eng.Sun.COM (Steve Clamage), 18 Jan 96

[...]

Suppose that function entry and exit are not atomic operations, which is
the case on all systems supporting C++ that I am aware of. The "critical
structure" is the stack frame. If asynchronous interrupts can occur, and
if you are going to require well-defined exception behavior from signal
handlers, then you must lock the entirety of every function preamble and
postamble. (You cannot know that an external signal won't occur.) That
requirement not only slows down function calls, it adds to interrupt
latency.

How expensive is it to lock and unlock every function entry and exit?
On some systems it is cheap. On others it is expensive. Considering that
a characteristic of OO programs is having many small functions, requiring
these locks could have a dramatic impact on program performance, even
for programs that don't want to throw exceptions from signal handlers.

What we put in the language standard is binding on all implementations. We
try to specify things that can be implemented efficiently on any likely
system. In addition, we try to specify features so that they have no cost
(or nearly no cost) if you don't use them. IMHO, guarantees about what you
can do in an asynchronous signal handler don't meet those criteria for
inclusion in the C++ standard.