From owner-svn-src-all@FreeBSD.ORG Sat Mar 3 15:43:40 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE403106576A; Sat, 3 Mar 2012 15:43:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail30.syd.optusnet.com.au (mail30.syd.optusnet.com.au [211.29.133.193]) by mx1.freebsd.org (Postfix) with ESMTP id 533F48FC16; Sat, 3 Mar 2012 15:43:39 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail30.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q23FhVSg025250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Mar 2012 02:43:32 +1100 Date: Sun, 4 Mar 2012 02:43:31 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Tijl Coosemans In-Reply-To: <201203031512.52057.tijl@freebsd.org> Message-ID: <20120304021957.O5936@besplex.bde.org> References: <201202282217.q1SMHrIk094780@svn.freebsd.org> <20120303110551.Q1494@besplex.bde.org> <20120303091426.GS75778@deviant.kiev.zoral.com.ua> <201203031512.52057.tijl@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Konstantin Belousov , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans Subject: Re: svn commit: r232275 - in head/sys: amd64/include i386/include pc98/include x86/include X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 15:43:40 -0000 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