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

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> Any idea how to proceed with this, Eli and Alan?
>
> 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.

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_output which loops,
AFAICT.

By immediately returning -1 in ns_select it additionally also does not
run [NSApp run], which means NS/Cocoa events will not be processed. If
nobody else (ns_read_socket, for instance) is called in
from somehwere we're stuckin 2 ways:

- Existing input_events in hold_event_q are never transferred to the
  rest of Emacs.
- NS events are never processed, which leads to the beach ball.

So, I tried the attached patch to ns_select, which does 2 things:

- it makes sure that hold_event_q input_events are transferred to Emacs.
- it makes sure that [NSApp run] is always called.

Not that I really know what I'm doing, but it seems to work ;-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ns_select patch --]
[-- Type: text/x-patch, Size: 1057 bytes --]

diff --git a/src/nsterm.m b/src/nsterm.m
index f094b145fe3..075d1af0938 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -4739,12 +4739,13 @@ Function modeled after x_draw_glyph_string_box ().
   check_native_fs ();
 #endif
 
-  if (hold_event_q.nr > 0 && !run_loop_only)
+  /* If there are input events pending, store them so that
+     Emacs can recognize C-g.  */
+  if (hold_event_q.nr > 0)
     {
-      /* We already have events pending.  */
-      raise (SIGIO);
-      errno = EINTR;
-      return -1;
+      for (int i = 0; i < hold_event_q.nr; ++i)
+        kbd_buffer_store_event_hold (&hold_event_q.q[i], NULL);
+      hold_event_q.nr = 0;
     }
 
   eassert (nfds <= FD_SETSIZE);
@@ -4757,7 +4758,7 @@ Function modeled after x_draw_glyph_string_box ().
   if (NSApp == nil
       || ![NSThread isMainThread]
       || (timeout && timeout->tv_sec == 0 && timeout->tv_nsec == 0))
-    return thread_select (pselect, nfds, readfds, writefds,
+    thread_select (pselect, nfds, readfds, writefds,
 			  exceptfds, timeout, sigmask);
   else
     {