Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 22 Dec 2022 09:28:58 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Under the GTK builds, there is only a single thread.  The event loop
> >> runs from the main thread.  Those calls to note_mouse_highlight *are*
> >> being done from the main thread.  The problem is that it is unsafe to
> >> signal in the main thread when handle_one_xevent is being called by
> >> GLib, because GLib does the equivalent of this:
> >> 
> >>   static bool inside_callback;
> >> 
> >>   assert (!inside_callback);
> >>   inside_callback = true;
> >>   [call handle_one_xevent]
> >>   inside_callback = false;
> >> 
> >> If handle_one_xevent signals, then inside_callback will never be set to
> >> false.  As a result, the next time GLib enters its own event dispatch
> >> code, it will abort, leading to the crash seen here.
> >
> > OK, so then I ask again: why not have the function called by GTK just
> > enqueue events and return, and then let read_socket_hook read the
> > enqueued events and process them as they are read, in keyboard.c?
> 
> After the function returns, it is not guaranteed that Emacs will be able
> to enter read_socket_hook soon.

Why is that a problem?  If the event we queue includes all the data
needed for processing it, why does it matter how soon it is processed?

And what could delay the processing significantly in this scenario?
Since these callbacks are called from the main thread, it means Emacs
is not busy, and should return to the main loop very soon.  Right?