bug#69561: 30.0.50; Freeze from M-x gnus on macOS

[Alan Third]

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