GNU bug report logs - #79228
30.1.90; native--compile-async sentinel can error if threads are running

Previous Next

Full log

Message #41 received at 79228 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dmitry <at> gutov.dev, acorallo <at> gnu.org, johnw <at> gnu.org, 79228 <at> debbugs.gnu.org
Subject: Re: bug#79228: 30.1.90; native--compile-async sentinel can error if
 threads are running
Date: Tue, 02 Sep 2025 09:18:12 -0400

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: acorallo <at> gnu.org,  johnw <at> gnu.org,  79228 <at> debbugs.gnu.org, Dmitry Gutov
>>   <dmitry <at> gutov.dev>
>> Date: Mon, 01 Sep 2025 15:10:59 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> >> Cc: acorallo <at> gnu.org,  johnw <at> gnu.org,  79228 <at> debbugs.gnu.org
>> >> Date: Mon, 01 Sep 2025 12:03:21 -0400
>> >> 
>> >> Eli Zaretskii <eliz <at> gnu.org> 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.

[0001-Allow-any-thread-to-run-native-compilation.patch (text/x-patch, inline)]

From d0f0e4b5471d188b483c35eb69086f2de60b5405 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Tue, 2 Sep 2025 09:17:06 -0400
Subject: [PATCH] Allow any thread to run native compilation

* lisp/emacs-lisp/comp-run.el (comp--run-async-workers): Don't
lock the native compilation process to a thread (bug#79228)
---
 lisp/emacs-lisp/comp-run.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/emacs-lisp/comp-run.el b/lisp/emacs-lisp/comp-run.el
index 1761190ea17..5e33b1bc318 100644
--- a/lisp/emacs-lisp/comp-run.el
+++ b/lisp/emacs-lisp/comp-run.el
@@ -366,6 +366,7 @@ comp--run-async-workers
                                                       (eq load1 'late))))
                                (comp--run-async-workers))
                              :noquery (not native-comp-async-query-on-exit))))
+              (set-process-thread process nil)
               (puthash source-file process comp-async-compilations))
          when (>= (comp--async-runnings) (comp--effective-async-max-jobs))
          do (cl-return)))
-- 
2.43.7

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.