[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45898: 27.1; wedged in redisplay again
From: |
Gerd Möllmann |
Subject: |
bug#45898: 27.1; wedged in redisplay again |
Date: |
Sat, 25 Jun 2022 11:49:42 +0200 |
> On 2022-06-25,, at 8:29 , Eli Zaretskii <eliz@gnu.org> wrote:
>
>> One of the first things that came to my mind is a new category "time fuse"
>> (in German Zeitzünder),
>> something counting ticks, and detonating (signaling) at some point. I admit
>> that I find the names you used
>> with redisplay in them confusing. Especially in the regexp code and so.
>
> That's mainly to keep the names from getting too long to be useful. I
> could have used something like update_display_code_iteration_ticks,
> but it looked to me that "redisplay" is a good way of saying "display
> code" shorter.
Well... update_display_code_iteration_ticks also makes me twitch because I
think of the tick/signal business not part of "display". What I have in my
head is regexp -> ticks, and iterator -> ticks, where "ticks" would be replaced
with some suitable name. I think regexp should also be interrupted with long
lines, when we match a line that is too long. Or not?
Or maybe "ticks" is already a good enough name? We could then simply have
update_ticks and good. Or eticks to not confuse it with time ticks, if that
ever happens.
>
>> Functionality-wise, Iterator now signals an error that redisplay catches.
>
> Yes, that's the main idea. But note that in some cases Iterator is
> called directly from Lisp, not from Redisplay, in which case the error
> is caught by the command loop (not sure where that is in your
> taxonomy? is that also Lisp?), not by Redisplay. Case in point: C-n.
Yes, that's what I meant by lisp -> iterator, using the move_it* "API".
I left out the command-loop, but it's also something I'd consider a category.
>
>> The error is signaled when a global tick counter exceeds a max value. Each
>> movement of an iterator
>> increments the global tick counter. The counter is global because you want
>> to sum up all the ticks that
>> occur between a given start point where the tick counter is set to 0, and
>> the point where the ticks exceed the
>> maximum, regardless of iterator -> lisp -> iterator nesting.
>>
>> The global tick counter is also incremented from regexp. I think font-lock
>> plays a role here. One scenario is
>> redisplay or lisp -> iterator, iterator needs font-lock to run (-> lisp),
>> font-lock matches a regexp (lisp ->
>> regexp), and we get stuck on a long line. Likewise with other stuff, like
>> syntax.
>
> Right. But I want to explain why I count ticks in regexp, in
> syntax.c, and in some places in bidi.c. The reason is that a single
> call to set_iterator_to_next, which basically counts as one tick, can
> sometimes result in prolonged operations. So some ticks are "more
> equal" than others, and I looked for a way of expressing that. What
> you see in those other places is the result of that: it makes
> iteration steps that trigger prolonged examination of buffer text to
> count as more than one tick.
I've seen that, and I think that's fine.
>
>> (BTW, the call to update the tick in regexp can lead to a GC when the error
>> is signaled, in the same way as
>> in bug 56108 with maybe_quit. So we might need that, too.)
>
> Yes, it could cause GC, but I'm not sure what you mean by "we might
> need that". What is "that" here?
I meant a fix for that bug.
Might be something specific to German. People say "I need that bug for the
next release", and mean the fix, because they have the bug already :-).
> Did you mean we should count ticks
> inside GC as well? If so, we'd need to have some way of preventing a
> signal when the tick count reaches the threshold, because we cannot
> signal an error inside GC.
No, I didn't think of that.
>> The meaning of display_working_on_window_p is not clear to me. I see what
>> setting it does in the end, but I
>> can't tell what this means:
>>
>> /* True while some display-engine code is working on layout of some
>> window.
>
> The reason for that kludge is the urge to avoid signaling an error
> when regexp or syntax.c is called in the context that is not related
> to any display code whatsoever. Since these functions don't know
> whether they are invoked by some code in Iterator or by Lisp, they
> will count the ticks regardless, and I don't want them to signal an
> error if they happen to count too many ticks.
You mean a case, where small numbers of ticks sum up by calling these Lisp
functions often enough?
>
>> Do you want me to take a deeper look at specific places?
>
> As you wish. I just wanted a second opinion on the overall design,
> and my main worry besides that is whether there are situations where
> this simple mechanism could cause trouble. E.g., Lars already
> uncovered one such situation, see
>
> https://lists.gnu.org/archive/html/emacs-diffs/2022-06/msg00761.html
>
> (I will redirect that to here, as emacs-diffs is not for discussions
> of this sort.)
Apart from features I don't know, I don't see any fundamental problem with your
approach.
- bug#45898: 27.1; wedged in redisplay again, (continued)
- bug#45898: 27.1; wedged in redisplay again, Stefan Monnier, 2022/06/21
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/21
- bug#45898: 27.1; wedged in redisplay again, Stefan Monnier, 2022/06/22
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/23
- bug#45898: 27.1; wedged in redisplay again, Stefan Monnier, 2022/06/23
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/24
- bug#45898: 27.1; wedged in redisplay again, Gerd Möllmann, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Gerd Möllmann, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again,
Gerd Möllmann <=
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Gerd Möllmann, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Gerd Möllmann, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Gerd Möllmann, 2022/06/25
- bug#45898: 27.1; wedged in redisplay again, Stefan Monnier, 2022/06/29
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/29
- bug#45898: 27.1; wedged in redisplay again, Stefan Monnier, 2022/06/29
- bug#45898: 27.1; wedged in redisplay again, Eli Zaretskii, 2022/06/30