bug#60144: 30.0.50; PGTK Emacs crashes after signal

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: karl@karlotness.com,  60144@debbugs.gnu.org
>> Date: Sun, 18 Dec 2022 17:52:42 +0800
>> 
>> > Why this fragile architecture of reading input events?  Calling
>> > functions of our Lisp machine from context where those functions
>> > cannot signal an error is very dangerous, and cannot work well in
>> > Emacs.  Why cannot we have the reads through GTK only deliver events
>> > to us, which we enqueue to our own event queue, and then we could
>> > process that queue in the safe context of the Lisp machine, as (AFAIK)
>> > we do on other platforms?
>> 
>> No, signalling there is equally unsafe on the other platforms, where
>> note_mouse_highlight is called from the same place(s): read_socket_hook,
>> event_handler_gdk, et cetera.  Just look at the callers of
>> x_note_mouse_movement in xterm.c, or [EmacsView mouseMoved:] in
>> nsterm.m.
>
> Sorry, I'm afraid I don't see the danger on other platforms.  Please
> explain.  AFAIK, read_socket_hook is called from keyboard.c code which
> reads input, and that code has no problem signaling an error.  What am
> I missing?

That code has problems signalling errors, unless it is okay for
unblock_input to signal.

On the regular X build with GTK, handle_one_xevent is called from
event_handler_gdk, which is called by GDK when it detects an event.
handle_one_xevent can also be called from x_dispatch_event inside a
popup menu, and during drag-and-drop.  On NS, [EmacsView mouseMoved:] is
called by the system from Objective-C.

Out of all of those places, the only place where it is safe to signal is
inside the drag-and-drop event loop.  Signalling out of the rest will
either lead to catastrophic blowups (if it happens inside
event_handler_gdk or [EmacsView mouseMoved:]), or to grabs never being
released and resource leaks inside a menu.