bug-gnu-emacs
[Top][All Lists]
Advanced

[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... :-)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]