all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#72496: 31.0.50; macOS: freezes without beach ball
@ 2024-08-06 13:39 Gerd Möllmann
  2024-08-06 14:53 ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Gerd Möllmann @ 2024-08-06 13:39 UTC (permalink / raw)
  To: 72496

In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin23.6.0, NS
 appkit-2487.70 Version 14.6 (Build 23G80)) of 2024-08-05 built on
 pro2.fritz.box
Repository revision: c7d9cd722e5a7042a52c92f8497f903bfe9870b8

This is one of the problems on macOS that I'm experiencing quite
often. I have no idea what is causing this, and I haven't found a way
to make it reproducible. I guess I should file a bug report anyway.

Let me first try to describe briefly how NS GUI event handling works
in Emacs.

The whole story starts with get_input_pending which calls gobble_input
which calls a terminal's read_socket_hook, which is ns_read_socket in
macOS. ns_read_socket calls [NSApplication run] to process macOS GUI
events.

The problem starts with [NSApplication run] being an endless loop that
gets the next event, and dispatches it by calling the application's
sendEvent method. The only way to make the run loop terminate is by
calling [NSApplication stop]. This sets a flag that [NSApplicatoin
run] is supposed to check and then return, so that we eventually
return to ns_read_socket.

We call [NSApplicaton stop] in our [EmacsApp sendEvent] method. To get
there, we post special application-defined events to the application
which [NSApplication run] processes and dispatches via sendEvent which
calls stop and makes [NSApplication run] return to its caller. Note
that stop only sets a flag, so we need to process another event to
make run terminate. That's at least my understanding.

We are posting these events all over the place, not only before
ns_read_socket calls [NSApplication run]. And, to complicate matters,
whether or not ns_send_appdefined actually posts an event depends on a
global boolean variable. IOW, it's impenetrable.

(I'm also leaving out the generation of input_events for Emacs here,
which is another can of worms.)

Problem is that this not always works. More specifically, this code in
ns_read_socket_1

          /* Run and wait for events.  We must always send one NX_APPDEFINED event
             to ourself, otherwise [NXApp run] will never exit.  */
          send_appdefined = YES;
          ns_send_appdefined (-1);

          [NSApp run];

gets stuck in the GUI event loop, and the last line never returns. The
effect being that Emacs freezes without a beach ball of death. It
processes Cocoa events but Emacs never sees any input_events.





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2024-08-10  9:18 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-08-06 13:39 bug#72496: 31.0.50; macOS: freezes without beach ball Gerd Möllmann
2024-08-06 14:53 ` Eli Zaretskii
2024-08-06 16:36   ` Gerd Möllmann
2024-08-06 18:04     ` Eli Zaretskii
2024-08-06 18:37       ` Gerd Möllmann
2024-08-08  5:24         ` Gerd Möllmann
2024-08-10  9:18           ` Gerd Möllmann

Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.