From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#25606: [DRAFT PATCH 2/2] Signal list cycles in =?UTF-8?Q?=E2=80=98length=E2=80=99?= etc. Date: Sat, 04 Feb 2017 11:05:06 +0200 Message-ID: <83y3xm8gxp.fsf@gnu.org> References: <20170201235622.30836-1-eggert@cs.ucla.edu> <20170201235622.30836-2-eggert@cs.ucla.edu> <83wpd8v6x8.fsf@gnu.org> <0a01d2ce-ef3e-7db0-6854-1b5e46d49be4@cs.ucla.edu> <83efzfvhbm.fsf@gnu.org> <08b0e359-3a9b-49f2-1299-51e899f86712@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1486199179 17778 195.159.176.226 (4 Feb 2017 09:06:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Feb 2017 09:06:19 +0000 (UTC) Cc: 25606@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Feb 04 10:06:15 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1cZwIQ-0004Di-Bn for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Feb 2017 10:06:14 +0100 Original-Received: from localhost ([::1]:38448 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZwIP-00047z-Cm for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Feb 2017 04:06:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZwII-00047s-Oa for bug-gnu-emacs@gnu.org; Sat, 04 Feb 2017 04:06:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZwIE-0000At-6T for bug-gnu-emacs@gnu.org; Sat, 04 Feb 2017 04:06:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57295) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cZwIE-0000Ah-2d for bug-gnu-emacs@gnu.org; Sat, 04 Feb 2017 04:06:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cZwID-00054p-SW for bug-gnu-emacs@gnu.org; Sat, 04 Feb 2017 04:06:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Feb 2017 09:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25606 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 25606-submit@debbugs.gnu.org id=B25606.148619913519482 (code B ref 25606); Sat, 04 Feb 2017 09:06:01 +0000 Original-Received: (at 25606) by debbugs.gnu.org; 4 Feb 2017 09:05:35 +0000 Original-Received: from localhost ([127.0.0.1]:55494 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZwHm-00054A-PR for submit@debbugs.gnu.org; Sat, 04 Feb 2017 04:05:34 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:39854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cZwHk-00053x-NY for 25606@debbugs.gnu.org; Sat, 04 Feb 2017 04:05:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cZwHb-0008PO-7E for 25606@debbugs.gnu.org; Sat, 04 Feb 2017 04:05:27 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cZwHb-0008PK-3i; Sat, 04 Feb 2017 04:05:23 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4849 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cZwHT-0006kL-Rq; Sat, 04 Feb 2017 04:05:17 -0500 In-reply-to: <08b0e359-3a9b-49f2-1299-51e899f86712@cs.ucla.edu> (message from Paul Eggert on Fri, 3 Feb 2017 12:29:11 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:128937 Archived-At: > Cc: 25606@debbugs.gnu.org > From: Paul Eggert > Date: Fri, 3 Feb 2017 12:29:11 -0800 > > On 02/02/2017 11:55 PM, Eli Zaretskii wrote: > > > the removal is probably justified for 90% of use cases, maybe > > even more > > It's 100% There is no 100% in real life, so if you want to convince me, you will never use such arguments. > as in practice any use case that has trouble because of the > code removal will have significantly worse trouble on every GC (which is > also noninterruptible). memq calls maybe_quit because of circular lists, > not because of lists of length 1 billion, as huge lists don't work well > with Emacs anyway (due to GC). I don't see how arguments related to GC are relevant to the issue at hand. I'm interested in only one aspect of this change: how it is a good idea to lose the ability to interrupt long loops processing large Lisp data structures. > 1. The benchmark was so large that Emacs froze my system while building > the test-case list, i.e., before any of the newly-affected code was > executed. This was due to page thrashing. Obviously the draft change is > irrelevant here. I disagree that a use case with a paging system is irrelevant. > 3. The benchmark was medium sized (in my case, this was a list with 100 > million entries), so that Emacs was painfully slow but still barely > usable while the test case was being built or while garbage collection > was being done. In this case, the new memq was the least of the user's > problems, as the new memq was 4x faster than a garbage collect so the > C-g was delayed annoyingly for GC anyway. That is, GC makes Emacs so > painful to use even with length-100-million lists that people won't use > Emacs that way and we don't need to worry about treating such lists > specially. Once again, the issue with GC is not relevant. And the fact that removing some code makes loops faster is trivial and also not relevant. I'm sorry, but I remain unconvinced that we should remove these calls. I'm okay with replacing maybe_quit with rarely_quit, which should strike some hopefully more optimal middle ground. > By the way, I have found many cases where Emacs master will loop forever > and will ignore C-g. If you like, I can privately send you an Elisp > expression that, if you evaluate it, you cannot C-g out of. This problem > is independent of the draft patch, and is far more serious than the > somewhat-theoretical discussion we're having about memq and friends. We need to solve those problems, but that doesn't mean we should introduce new ones elsewhere. Being able to interrupt long loops in Emacs is an important feature. Thanks.