[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44818: 27.0.91; wedged
From: |
Eli Zaretskii |
Subject: |
bug#44818: 27.0.91; wedged |
Date: |
Wed, 25 Nov 2020 17:06:02 +0200 |
> Cc: 44818@debbugs.gnu.org
> From: Devon Sean McCullough <Emacs-hacker2018@jovi.net>
> Date: Tue, 24 Nov 2020 20:35:00 -0500
>
> On 24/11/2020 13:48, Eli Zaretskii wrote:
> >> Cc: 44818@debbugs.gnu.org
> >> From: Devon Sean McCullough <Emacs-hacker2018@jovi.net>
> >> Date: Tue, 24 Nov 2020 13:42:03 -0500
> >>
> >> P.S. Could a watchdog timer safely abort such wedgitude?
> >
> > That would have to run in a separate thread, right?
> >
> > But what timeout to set it to? some jobs might legitimately take some
> > time. And then what to do when the timer expires?
>
> The job of redisplay cannot legitimately take > 50 milliseconds.
It can, and it does. Although this is quite rare, it does happen.
Here's a simple example: visit src/xdisp.c, then type M-> and measure
the time.
> When the user repeatedly tries ^G quit but Emacs is unresponsive
> because of redisplay, such redisplay must be prevented while the
> user is offered options to regain control.
I asked "what to do when the timer expires" because the practical
meaning of "redisplay must be prevented" is not at all clear.
> P.S. Could an invisibility overlay offer temporary relief?
> Perhaps a red screen of redisplay death with a short menu?
Anything that has to be done by the display code will suffer from the
same problem.
- bug#44818: 27.0.91; wedged, (continued)
- bug#44818: 27.0.91; wedged, Devon Sean McCullough, 2020/11/24
- bug#44818: 27.0.91; wedged,
Eli Zaretskii <=
- bug#44818: 27.0.91; wedged, Devon Sean McCullough, 2020/11/26
- bug#44818: 27.0.91; wedged, Richard Stallman, 2020/11/27
- bug#44818: 27.0.91; wedged, Michael Albinus, 2020/11/27
bug#44818: Looks like I retitled both bugs, 積丹尼 Dan Jacobson, 2020/11/27