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

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: 69561 <at> debbugs.gnu.org
Cc: Alan Third <alan <at> idiocy.org>
Subject: Re: bug#69561: 30.0.50; Freeze from M-x gnus on macOS
Date: Thu, 07 Mar 2024 16:18:00 +0100

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

Previous Next

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