emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: bug#60144: 30.0.50; PGTK Emacs crashes after signal
Date: Wed, 21 Dec 2022 15:06:00 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]