From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Using the GNU GMP Library for Bignums in Emacs Date: Mon, 23 Apr 2018 18:18:59 +0300 Message-ID: <83lgdevtlo.fsf@gnu.org> References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <87k1t05wz4.fsf@metalevel.at> <55776605-8940-0a4a-34fb-f3d1b955ab12@cs.ucla.edu> <831sf8x8o6.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1524496644 5218 195.159.176.226 (23 Apr 2018 15:17:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 23 Apr 2018 15:17:24 +0000 (UTC) Cc: eggert@cs.ucla.edu, triska@metalevel.at, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 23 17:17:19 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fAdDS-0001Et-PP for ged-emacs-devel@m.gmane.org; Mon, 23 Apr 2018 17:17:18 +0200 Original-Received: from localhost ([::1]:53996 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fAdFZ-0000MC-H3 for ged-emacs-devel@m.gmane.org; Mon, 23 Apr 2018 11:19:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50825) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fAdFS-0000Ln-BI for emacs-devel@gnu.org; Mon, 23 Apr 2018 11:19:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fAdFN-0007vR-5d for emacs-devel@gnu.org; Mon, 23 Apr 2018 11:19:22 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fAdFN-0007vK-1L; Mon, 23 Apr 2018 11:19:17 -0400 Original-Received: from [176.228.60.248] (port=3435 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fAdFF-0003tf-AF; Mon, 23 Apr 2018 11:19:09 -0400 In-reply-to: (message from Richard Stallman on Sun, 22 Apr 2018 23:34:58 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:224810 Archived-At: > From: Richard Stallman > CC: eggert@cs.ucla.edu, triska@metalevel.at, emacs-devel@gnu.org > Date: Sun, 22 Apr 2018 23:34:58 -0400 > > Quiting always worked by setting a flag, tested by the QUIT macro. > However, as I implemented it, some constructs used to specify to quit > immediately straight from the signal handler. This still happens, but much less frequently: only on text-mode frames, and only when Emacs waits for input. > I see that this feature has been deleted. That is going to cause a > bad results. There are quite a few places in the C code of Emacs > where execution can get stuck; that's why I added immediate quitting. > The problems I fixed that way have all come back. > > What was the reason for this change? The main reasons were described and discussed in bug#12471, in the context of making signal handling in Emacs more robust. I reproduce that description below. In addition, the asynchronous input code caused problems and limitations, the most (in)famous being that we needed to refrain from calling malloc in places that could be potentially run from the signal handler. Also note this discussion about actually making synchronous input the default one: http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg00410.html And here's your agreement to making that the default: http://lists.gnu.org/archive/html/emacs-devel/2008-03/msg01268.html ---------------------------------------------------------------------- * Signal handlers can interrupt each other, leading to races. * Signals can be mishandled if they arrive right in the middle of code that is keeping track of whether signals have arrived. * Some variables are modified by signal handlers but are not declared 'volatile', which means accesses to them could be incorrectly optimized. * When debugging, the debugging code can get into an infinite signal-handling loop if there's a bug in the fatal error handler. * There are some bugs involving running out of memory in the middle of a vfork, in which signal handlers aren't restored correctly and Emacs is likely to misbehave. * Signals are always redirected to the main thread, resulting in incorrect backtraces when, for example, a subsidiary thread has a segmentation violation. Thread-specific signals like SIGSEGV should have thread-specific backtraces. * When in batch mode, Emacs doesn't ignore SIGINT if the invoker has purposely ignored SIGINT. Similarly for SIGTERM. Emacs gets SIGHUP right, but the other two signals should be consistent with the usual behavior for batch programs. * Emacs isn't consistent about what tests it uses to decide whether it is in batch mode, leading to glitches when the tests disagree. * Emacs catches SIGPIPE, but it's better to ignore it, as this avoids races. * Emacs catches SIGFPE, but on IEEE hosts catching SIGFPE isn't needed and can mask bugs; it's better to catch SIGFPE only on (the now quite rare) non-IEEE hosts.