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

Previous Next

Package: emacs;

Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Date: Tue, 5 Mar 2024 11:03:01 UTC

Severity: normal

Found in version 30.0.50

Fixed in version 30.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 69561 <at> debbugs.gnu.org, alan <at> idiocy.org
Subject: Re: bug#69561: 30.0.50; Freeze from M-x gnus on macOS
Date: Sat, 09 Mar 2024 09:33:55 +0200
> Cc: 69561 <at> debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Thu, 07 Mar 2024 20:29:44 +0100
> 
> Alan Third <alan <at> idiocy.org> writes:
> 
> >> Thanks. That's in if (read_kbd), and the first backtrace I sent had
> >> 
> >>     frame #6: 0x00000001001d94d2
> >> emacs`wait_reading_process_output(time_limit=<unavailable>,
> >> nsecs=<unavailable>, read_kbd=0, do_display=false,
> >> wait_for_cell=(struct Lisp_Symbol *) $123 = 0x00000001007d24b0,
> >> wait_proc=0x00007fccffdcc9d8, just_wait_proc=0) at process.c:5484:9
> >> [opt]
> >> 
> >> i.e. read_kbd should be 0.
> >> 
> >> Maybe that's also an explanation why it doesn't freeze most of time?
> >> If it sometimes does detect_input_pending...
> >
> > So this
> >
> >    READ_KBD is:
> >      0 to ignore keyboard input, or
> >      1 to return when input is available, or
> >     -1 meaning caller will actually read the input, so don't throw to
> >        the quit handler
> >
> > implies that if read_kbd is zero then we should be able to quit?
> 
> I'm afraid I can't answer that. Maybe Eli can, or knows someone who can?

I think the fragment below answers the question?

      /* If calling from keyboard input, do not quit
	 since we want to return C-g as an input character.
	 Otherwise, do pending quit if requested.  */
      if (read_kbd >= 0)
	maybe_quit ();

So yes, if read_kbd is zero, we should be able to quit.

> > If that's the case then we need some special handling in nsterm.m for
> > C-g, I suppose.
> >
> > Having dug around in other terms I assume this means setting
> > Vquit_flag? So in the keyDown method we should identify C-g and set
> > Vquit_flag...?
> 
> As far as I understand the code, Vquit_flag will also be set by storing
> the event in question with kbd_buffer_store_event_hold. I think that
> would be the easiest way. And it's what ns_read_socket already does.

Setting Vquit_flag directly has the advantage that it will cause C-g
to be processed earlier, without waiting for all the previous queued
inputs to be processed first.  In general, users expect C-g to be
processed ASAP.




This bug report was last modified 1 year and 124 days ago.

Previous Next


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