bug#25606: [DRAFT PATCH 2/2] Signal list cycles in ‘length’ etc.

[Eli Zaretskii]

> Cc: 25606@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 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.