[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#69561: 30.0.50; Freeze from M-x gnus on macOS
From: |
Gerd Möllmann |
Subject: |
bug#69561: 30.0.50; Freeze from M-x gnus on macOS |
Date: |
Sat, 09 Mar 2024 10:47:43 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Eli Zaretskii <eliz@gnu.org> writes:
>> 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.
Thanks!
>
>> > 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.
Ok, I now tried with this in keyDown, applied to current master, no
other changes. (keyDown is somewhat scary, if I may remark that ;-).
C-g is then recognized and Vquit_flag is set under normal circumstances,
which I can see on stderr.
diff --git a/src/nsterm.m b/src/nsterm.m
index f094b145fe3..a9539987411 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -6875,10 +6878,17 @@ In that case we use UCKeyTranslate
(ns_get_shifted_character)
of characters? */
emacs_event->kind = code > 0xFF
? MULTIBYTE_CHAR_KEYSTROKE_EVENT : ASCII_KEYSTROKE_EVENT;
- }
+ }
+
+ // This is probably wrong, it's just for testing.
+ if (code == 'g' && (emacs_event->modifiers & ctrl_modifier))
+ {
+ fprintf (stderr, "C-g\n");
+ Vquit_flag = Qt;
+ }
emacs_event->code = code;
- EV_TRAILER (theEvent);
+ EV_TRAILER (theEvent);
processingCompose = NO;
return;
}
It didn't help in a freeze though. Apparently, keyDown isn't called
then, i.e. there's no output on stderr.
On second thought, I should probably have expected that, because the
system says that Emacs is unresponsive, which I think means it doesn't
process events.
So, that alone apparently doesn't help, although it appears it should be
done (in the right way, which I'm not sure I know.)
News from the last patch I sent for ns_select - I didn't have a freeze
with it so far, and I didn't observe any adverse effects either. So far
so good...
Any idea how to proceed with this, Eli and Alan?
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, (continued)
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Alan Third, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Alan Third, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Alan Third, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/07
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Eli Zaretskii, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS,
Gerd Möllmann <=
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Eli Zaretskii, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Eli Zaretskii, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Eli Zaretskii, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Eli Zaretskii, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/09
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Gerd Möllmann, 2024/03/13
- bug#69561: 30.0.50; Freeze from M-x gnus on macOS, Filipp Gunbin, 2024/03/13