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

Previous Next

Package: emacs;

Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Date: Tue, 5 Mar 2024 11:03:01 UTC

Severity: normal

Found in version 30.0.50

Fixed in version 30.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Alan Third <alan <at> idiocy.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 69561 <at> debbugs.gnu.org
Subject: Re: bug#69561: 30.0.50; Freeze from M-x gnus on macOS
Date: Thu, 7 Mar 2024 16:05:55 +0000
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...".

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.
-- 
Alan Third




This bug report was last modified 1 year and 125 days ago.

Previous Next


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