From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Using the GNU GMP Library for Bignums in Emacs Date: Mon, 23 Apr 2018 21:34:58 -0700 Organization: UCLA Computer Science Department Message-ID: References: <29f933ac-a6bf-8742-66a7-0a9d6d3e5a88@disroot.org> <87k1t05wz4.fsf@metalevel.at> <55776605-8940-0a4a-34fb-f3d1b955ab12@cs.ucla.edu> <831sf8x8o6.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1524544392 2410 195.159.176.226 (24 Apr 2018 04:33:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 24 Apr 2018 04:33:12 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 Cc: eliz@gnu.org, 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 Tue Apr 24 06:33:08 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 1fApda-0000Vj-V9 for ged-emacs-devel@m.gmane.org; Tue, 24 Apr 2018 06:33:07 +0200 Original-Received: from localhost ([::1]:56464 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fApfg-0008MA-7J for ged-emacs-devel@m.gmane.org; Tue, 24 Apr 2018 00:35:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fApfa-0008K7-OP for emacs-devel@gnu.org; Tue, 24 Apr 2018 00:35:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fApfZ-0007YW-Vr for emacs-devel@gnu.org; Tue, 24 Apr 2018 00:35:10 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:58416) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fApfU-0007Vi-QF; Tue, 24 Apr 2018 00:35:05 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A153C1600BA; Mon, 23 Apr 2018 21:35:02 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id xwPD68fFjBC7; Mon, 23 Apr 2018 21:35:01 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D68891600B2; Mon, 23 Apr 2018 21:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jpVF_iWKmFH3; Mon, 23 Apr 2018 21:35:01 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id AD21C1600AC; Mon, 23 Apr 2018 21:35:01 -0700 (PDT) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 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:224824 Archived-At: Richard Stallman wrote: > > In the old days we could assume that execution order at the > > machine level was the same order as in the C program source code, > > which meant that as long as the C source code did things in the > > right order Emacs could survive immediate quitting. That > > assumption is no longer true. >=20 > That problem exists in theory. Did the problem actually occur? As Eli wrote, we did make the change in response to a bug report. I do no= t=20 recall all the details offhand. The theory is pretty clear, though. > If (2) means to check for quitting as needed in each and every place > code where immediate_quit was formerly used, that would thoroughly do > the job, but did we handle all of those places? We attempted to check for quitting at every place where a check is needed= to=20 avoid unbounded or too-long computation, and I recall using the immediate= _quits=20 in the old code as a cue for where to check for quitting in the new code.= We=20 tried to be conservative about this, and as I recall we put in some check= s even=20 when we weren't sure they were needed. Perhaps we missed some places, but= if so=20 we can fix them as problems arise (and in this sense the new method is si= milar=20 to the old one).