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

From: Spencer Baugh <[email-masked]>
Date: Mon, 01 Sep 2025 12:03:21 -0400

Eli Zaretskii <[email-masked]> writes:

>> From: Spencer Baugh <[email-masked]>
>> Cc: [email-masked],  [email-masked],  [email-masked]
>> Date: Mon, 01 Sep 2025 11:20:58 -0400
>> 
>> Eli Zaretskii <[email-masked]> writes:
>> 
>> >> From: Spencer Baugh <[email-masked]>
>> >> Date: Mon, 1 Sep 2025 08:54:58 -0400
>> >> Cc: Eli Zaretskii <[email-masked]>, [email-masked], [email-masked]
>> >> 
>> >> On Mon, Sep 1, 2025, 3:52 AM Andrea Corallo <[email-masked]> wrote:
>> >> 
>> >>  Eli Zaretskii <[email-masked]> writes:
>> >> 
>> >>  Hi Eli,
>> >> 
>> >>  must say I, like you, still don't understand the issue here.
>> >> 
>> >>  Spencer which threads are we talking about?  Native async compilation
>> >>  spawn processes not threads.
>> >> 
>> >> Lisp threads - the thread API in Emacs Lisp.
>> >
>> > Are you talking about some 3rd-party package?  If not, how come
>> > threads come into the picture when native-compilation is involved?
>> >
>> > IOW, would you please describe the situation from its very beginning,
>> > assuming someone runs something from "emacs -Q"?  Otherwise, it is
>> > very hard to understand what kind of situations could cause async
>> > processes running native compilation to be locked to the wrong
>> > threads.
>> 
>> 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.

>> Thus the native compilation can happen in a non-main thread.
>
> So step 3 is not necessary?

It's necesary because, of course, if nothing causes native compilation
to happen, native compilation won't happen.