Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 Mar 2012 02:43:31 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Tijl Coosemans <tijl@freebsd.org>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au>
Subject:   Re: svn commit: r232275 - in head/sys: amd64/include i386/include pc98/include x86/include
Message-ID:  <20120304021957.O5936@besplex.bde.org>
In-Reply-To: <201203031512.52057.tijl@freebsd.org>
References:  <201202282217.q1SMHrIk094780@svn.freebsd.org> <20120303110551.Q1494@besplex.bde.org> <20120303091426.GS75778@deviant.kiev.zoral.com.ua> <201203031512.52057.tijl@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120304021957.O5936>