bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Eli Zaretskii
Subject: bug#69561: 30.0.50; Freeze from M-x gnus on macOS
Date: Sat, 09 Mar 2024 15:08:51 +0200

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: alan@idiocy.org,  69561@debbugs.gnu.org
> Date: Sat, 09 Mar 2024 12:33:51 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: alan@idiocy.org,  69561@debbugs.gnu.org
> >> Date: Sat, 09 Mar 2024 12:00:36 +0100
> >> 
> >> > I'm afraid I've lost the relevant context.  Can you remind why Emacs
> >> > is not responsive? does it infloop somewhere, and if so, where?
> >> 
> >> Yes, it loops in wait_reading_process_out, which calls ns_select without
> >> making progress, and without handling NS events, which is the reason why
> >> the system says Emacs is unresponsice (beach ball of death).
> >> 
> >> This can happen in various circumstances. I have seen freezes in epg
> >> (decrypting autoinfo), flymake, json-rps (eglot + clangd) so far. And it
> >> started to get really bad lately in master, for unknown reasons.
> >> 
> >> My analysis, all the usual disclaimers apply ;-)...
> >> 
> >> The NS port event handling works like so: NS 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. NS events are
> >> processed by calling [NSApp run] with some ornamention around it to make
> >> sure the call 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.
> >
> > Are we talking about processing C-g or are we talking about processing
> > "normal" output from sub-processes?  I thought we were talking about
> > the latter?  If so, then C-g is not really relevant, and we need to
> > establish why stuff that comes from the sub-process is not processed
> > as we expect, by causing ns_select return something interesting.
> > Right?
> 
> Right, sorry, C-g came only into play because I tbought the current
> sitution might become bearable if it could at least be interrupted with
> C-g. And then I understoof the drama better.
> 
> If you take a look at the first hunk of the patch I sent, you can see
> that ns_select can do _nothing_ interesting at all, it just returns -1.

But your patch still doesn't solve the problem, does it?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]