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 _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
