I am reading The Design and Evolution of C++, by Bjarne Stroustrup. Regarding exeception handling and asynchronous signals it is mentioned as below:
Can exceptions be used to handle things like signals? Almost certainly not in most C environments. The trouble is that C uses functions like malloc that are not re-entrant. If an interrupt occurs in the middle of malloc and causes an exception, there is no way to prevent the exception handler from executing malloc again.
A C++ implementation where calling sequences and the entire run-time library are designed around the requirement for re-entrancy would make it possible for signals to throw exceptoins
What does the author mean by the statement "there is no way to prevent the exception handler from executing malloc again"? How would making functions re-entrant make it possible to throw exceptions from signal handlers?
In my opinion that part doesn’t really make much sense with current C++.
In C++ there is no way to use an exception as a signal because signals are meant to be executing an handler and then (possibly) continue execution.
C++ exceptions however don’t work this way. Once you get to the exception handler the stack has been already rolled back and there is no way to “continue” after the handling: there is no way to get to the statement following a throw (or following a function call during which an exception gets thrown).
Signals are asynchronous but not disruptive and continuing after a signal is possible (even if of course care must be taken about what is done in the signal handler), exceptions instead are disruptive of the program flow and continuing is impossible.
I’d say the two ideas are incompatible at a logical level and doesn’t really matter if the library is reentrant or not.
May be in early C++ design there was a resume option for exceptions…