GNU bug report logs - #69561
30.0.50; Freeze from M-x gnus on macOS

Previous Next

Full log

Message #35 received at 69561 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 69561 <at> debbugs.gnu.org
Subject: Re: bug#69561: 30.0.50; Freeze from M-x gnus on macOS
Date: Thu, 07 Mar 2024 17:30:28 +0100

Alan Third <alan <at> 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... :-)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.