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

[Po Lu <luangruo@yahoo.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 21 Dec 2022 09:01:01 +0800
>> 
>> There is some kind of misunderstanding here.  You seem to be talking
>> about calling Lisp from another thread, which is a big no-no in my book
>> as well.  However, the problem is nowhere near as drastic.
>> 
>> 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.

(Sorry if this mail reaches you multiple times: the mail server is
having issues.)