Subject: Re: bug#79228: 30.1.90; native--compile-async sentinel can error if threads are running

From: Eli Zaretskii <[email-masked]>
Date: Tue, 02 Sep 2025 14:14:15 +0300

> From: Spencer Baugh <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked], Dmitry Gutov
>   <[email-masked]>
> Date: Mon, 01 Sep 2025 15:10:59 -0400
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >> From: Spencer Baugh <[email-masked]>
> >> Cc: [email-masked],  [email-masked],  [email-masked]
> >> Date: Mon, 01 Sep 2025 12:03:21 -0400
> >> 
> >> Eli Zaretskii <[email-masked]> 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.