Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: acorallo@gnu.org, johnw@gnu.org, 79228@debbugs.gnu.org, Dmitry Gutov >> >> Date: Mon, 01 Sep 2025 15:10:59 -0400 >> >> Eli Zaretskii writes: >> >> >> From: Spencer Baugh >> >> Cc: acorallo@gnu.org, johnw@gnu.org, 79228@debbugs.gnu.org >> >> Date: Mon, 01 Sep 2025 12:03:21 -0400 >> >> >> >> Eli Zaretskii writes: >> >> >> >> >> 1. emacs -Q >> >> >> 2. Run some command which starts a thread >> >> >> 3. Run some command which starts native compilation >> >> >> >> >> >> Native compilation is done via pending_funcalls. pending_funcalls can >> >> >> be run in the non-main thread started by 2. >> >> > >> >> > How? >> >> >> >> Because pending_funcalls is run by timer_check_2, which is run by >> >> timer_check, which is run by wait_reading_process_output, which can be >> >> run by non-main threads. >> > >> > So maybe we should run timers only in the main thread? >> >> That would break, for example, with-timeout. > > So? I'm not at all surprised that timers and threads, two very > different ways of having the same pseudo-parallel execution in Emacs, > do not live together in peace. > >> Alternatively, if we stopped locking processes to threads, this problem >> would also be fixed. > > That's too radical, and has too many downsides, as already discussed. > And it's unjustified, since if worse comes to worst, we can simply > unlock the process that performs async compilation. No need to reach > far-fetched conclusions about processes in general because of this > specific case. Okay, then this patch should fix the bug.