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

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: alan@idiocy.org,  69561@debbugs.gnu.org
> Date: Sat, 09 Mar 2024 12:00:36 +0100
> 
> > I'm afraid I've lost the relevant context.  Can you remind why Emacs
> > is not responsive? does it infloop somewhere, and if so, where?
> 
> Yes, it loops in wait_reading_process_out, which calls ns_select without
> making progress, and without handling NS events, which is the reason why
> the system says Emacs is unresponsice (beach ball of death).
> 
> This can happen in various circumstances. I have seen freezes in epg
> (decrypting autoinfo), flymake, json-rps (eglot + clangd) so far. And it
> started to get really bad lately in master, for unknown reasons.
> 
> My analysis, all the usual disclaimers apply ;-)...
> 
> The NS port event handling works like so: NS 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. NS events are
> processed by calling [NSApp run] with some ornamention around it to make
> sure the call 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.

Are we talking about processing C-g or are we talking about processing
"normal" output from sub-processes?  I thought we were talking about
the latter?  If so, then C-g is not really relevant, and we need to
establish why stuff that comes from the sub-process is not processed
as we expect, by causing ns_select return something interesting.
Right?