[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69561: 30.0.50; Freeze from M-x gnus on macOS
From: |
Gerd Möllmann |
Subject: |
bug#69561: 30.0.50; Freeze from M-x gnus on macOS |
Date: |
Sat, 09 Mar 2024 12:33:51 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: alan@idiocy.org, 69561@debbugs.gnu.org
>> Date: Sat, 09 Mar 2024 12:00:36 +0100
>>
>> > I'm afraid I've lost the relevant context. Can you remind why Emacs
>> > is not responsive? does it infloop somewhere, and if so, where?
>>
>> Yes, it loops in wait_reading_process_out, which calls ns_select without
>> making progress, and without handling NS events, which is the reason why
>> the system says Emacs is unresponsice (beach ball of death).
>>
>> This can happen in various circumstances. I have seen freezes in epg
>> (decrypting autoinfo), flymake, json-rps (eglot + clangd) so far. And it
>> started to get really bad lately in master, for unknown reasons.
>>
>> My analysis, all the usual disclaimers apply ;-)...
>>
>> The NS port event handling works like so: NS has a queue named
>> hold_events_q of struct input_event (global variable). The queue is
>> filled when EmacsView receives NS events from the system. NS events are
>> processed by calling [NSApp run] with some ornamention around it to make
>> sure the call returns. ns_select and ns_read_socket do that.
>>
>> The input_events in hold_events_q are given to Emacs in ns_read_socket,
>> which is installed for terminal type as read_socket_hook. That's how
>> normally a C-g is recognized by kdb_store_event and Vquit_flag is set.
>
> Are we talking about processing C-g or are we talking about processing
> "normal" output from sub-processes? I thought we were talking about
> the latter? If so, then C-g is not really relevant, and we need to
> establish why stuff that comes from the sub-process is not processed
> as we expect, by causing ns_select return something interesting.
> Right?
Right, sorry, C-g came only into play because I tbought the current
sitution might become bearable if it could at least be interrupted with
C-g. And then I understoof the drama better.
If you take a look at the first hunk of the patch I sent, you can see
that ns_select can do _nothing_ interesting at all, it just returns -1.
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, (continued)
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Alan Third, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Eli Zaretskii, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Eli Zaretskii, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Eli Zaretskii, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS,
Gerd Möllmann <=
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Eli Zaretskii, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Eli Zaretskii, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/13
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Filipp Gunbin, 2024/03/13
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/13
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/13
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Filipp Gunbin, 2024/03/13
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/13