[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: |
Thu, 07 Mar 2024 17:30:28 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Alan Third <alan@idiocy.org> writes:
> On Thu, Mar 07, 2024 at 04:18:00PM +0100, Gerd Möllmann wrote:
>> (CC'd to Alan.)
>>
>> As a reminder, the freezes are especially annoying because one cannot
>> C-g out of them. I read the NS code today, and I think I at least have a
>> strong suspicion why that is.
>>
>> Let's just simplify things and say that the NS code 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, for example
>> C-g. NS events are processed by calling [NSApp run] with some
>> ornamention around it to make sure the calls 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.
>>
>> But hold_events_q are _not_ kbd_store'd in ns_select. Instead we have
>>
>> if (hold_event_q.nr > 0 && !run_loop_only)
>> {
>> /* We already have events pending. */
>> raise (SIGIO);
>> errno = EINTR;
>> return -1;
>> }
>>
>> So, ns_select returns -1 to wait_reading_process_out which loops,
>> AFAICT.
>>
>> if (nfds < 0)
>> {
>> if (xerrno == EINTR)
>> no_avail = 1;
>> ...
>> if (no_avail || nfds == 0)
>> continue;
>>
>> And Vquit_flag is never changing because the C-g is still in
>> hold_events_q, and maybe_quit does nothing.
>>
>> Does that make sense?
>
> But keyboard input (ns_read_socket) is handled immediately after that
> "if (nfds < 0)" block and well before the "if (no_avail...".
Could you please tell the line number?
> That would imply to me that keyboard input, and therefore the C-g, is
> being blocked for some reason. Perhaps block_input() has been called?
>
> I'm no expert on how this part of Emacs works so I'm probably
> completely misunderstanding this.
Me neither, so many things have changed in only 20 years... :-)
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/05
- 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, Alan Third, 2024/03/07
- 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, 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, 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