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

[Alan Third]

On Thu, Mar 07, 2024 at 06:01:02PM +0100, Gerd Möllmann wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > On Thu, Mar 07, 2024 at 05:30:28PM +0100, Gerd Möllmann wrote:
> >> Alan Third <alan@idiocy.org> writes:
> >> 
> >> > But keyboard input (ns_read_socket) is handled immediately after that
> >> > "if (nfds < 0)" block and well before the "if (no_avail...".
> >> 
> >> Could you please tell the line number?
> >
> > detect_input_pending_run_timers at process.c:5839 calls
> > get_input_pending which calls gobble_input which calls
> > t->read_socket_hook.
> >
> > There seem to be a lot of ways for it to bail out, though.
> 
> 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?

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

-- 
Alan Third