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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

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

GLib might be in the middle of doing something itself, such as waiting
for file I/O, when it calls handle_one_xevent.

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

Right, for some definition of "soon".

I tried moving the processing to pgtk_read_socket.  But on the PGTK
build, GTK apparently expects changes to the mouse pointer to be applied
inside the call to the motion handler function, so now the cursor image
is not updated during mouse motion.

And for whatever reason, gdk_display_flush leads to a deadlock somewhere
in GDK.  I will investigate that later.