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

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

(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?