svn commit: r232275 - in head/sys: amd64/include i386/include pc98/include x86/include

[Bruce Evans]

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
full reentrancy).

Bruce