unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: 69561@debbugs.gnu.org, alan@idiocy.org
Subject: bug#69561: 30.0.50; Freeze from M-x gnus on macOS
Date: Sat, 09 Mar 2024 09:33:55 +0200	[thread overview]
Message-ID: <864jdfzwnw.fsf@gnu.org> (raw)
In-Reply-To: <m2v85xkfh3.fsf@Pro.fritz.box> (message from Gerd Möllmann on Thu, 07 Mar 2024 20:29:44 +0100)

> Cc: 69561@debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Thu, 07 Mar 2024 20:29:44 +0100
> 
> Alan Third <alan@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.





  parent reply	other threads:[~2024-03-09  7:33 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-05 10:59 bug#69561: 30.0.50; Freeze from M-x gnus on macOS Gerd Möllmann
2024-03-05 11:04 ` Gerd Möllmann
2024-03-05 14:29   ` Gerd Möllmann
2024-03-05 15:46     ` Eli Zaretskii
2024-03-05 16:38       ` Gerd Möllmann
2024-03-05 16:52         ` Eli Zaretskii
2024-03-05 17:54           ` Gerd Möllmann
2024-03-07 15:18     ` Gerd Möllmann
2024-03-07 15:52       ` Gerd Möllmann
2024-03-07 16:05       ` Alan Third
2024-03-07 16:30         ` Gerd Möllmann
2024-03-07 16:49           ` Alan Third
2024-03-07 17:01             ` Gerd Möllmann
2024-03-07 18:47               ` Alan Third
2024-03-07 19:29                 ` Gerd Möllmann
2024-03-07 20:23                   ` Gerd Möllmann
2024-03-08  4:31                     ` Gerd Möllmann
2024-03-09  7:33                   ` Eli Zaretskii [this message]
2024-03-09  9:47                     ` Gerd Möllmann
2024-03-09 10:07                       ` Eli Zaretskii
2024-03-09 11:00                         ` Gerd Möllmann
2024-03-09 11:11                           ` Eli Zaretskii
2024-03-09 11:33                             ` Gerd Möllmann
2024-03-09 13:08                               ` Eli Zaretskii
2024-03-09 13:21                                 ` Gerd Möllmann
2024-03-09 13:27                                   ` Eli Zaretskii
2024-03-09 13:51                                     ` Gerd Möllmann
2024-03-13  6:11                                       ` Gerd Möllmann
2024-03-13 16:53                                         ` Filipp Gunbin
2024-03-13 18:18                                           ` Gerd Möllmann
2024-03-13 18:20                                           ` Gerd Möllmann
2024-03-13 19:20                                             ` Filipp Gunbin
2024-03-13 19:37                                               ` Gerd Möllmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=864jdfzwnw.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=69561@debbugs.gnu.org \
    --cc=alan@idiocy.org \
    --cc=gerd.moellmann@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).