On Sat, 3 Mar 2012, Tijl Coosemans wrote:
> On Saturday 03 March 2012 10:14:26 Konstantin Belousov wrote:
>> longjmp() from a signal handler has very high chance of providing
>> wrong CPU state for anything except basic integer registers.
Not really, and return from a SIGFPE handler has a chance of 100% of
providing undefined behaviour in both theory and practice. (The
undefined behaviour includes working because the signal handler
fixed the problem, but that is too hard for most cases.)
> And the signal might have interrupted a function that isn't reentrant,
> so you can still only call async-signal-safe functions after the
> longjmp. It doesn't really leave the signal handler context.
It is the responsibility of the application not to allow the non-reentrant
case if it wants to handle signals by longjmp()ing from signal handlers.
This is not very hard to arrange, with some useful results, by keeping
the scopes of jmp_bufs small. E.g., around a read(2) loop, where the
read() might hang and you plan to let it be killed by a SIGINT, or around
some long FP calculation using local variables, where you fear that the
calculation might divide by 0 or something, and you want to trap the
exception and abort as soon as it happens, and don't want to check for
division by 0 throught the calculation or at the end. Some cases with
globals are safe too. E.g., if you are initializing a data struct but will
discard it all if there there is a signal. The read() loop into global
storage is a special case (read into local storage for an example with