GNU bug report logs -
#79228
30.1.90; native--compile-async sentinel can error if threads are running
Previous Next
Full log
Message #26 received at 79228 <at> debbugs.gnu.org (full text, mbox):
> 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 11:20:58 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> Date: Mon, 1 Sep 2025 08:54:58 -0400
> >> Cc: Eli Zaretskii <eliz <at> gnu.org>, johnw <at> gnu.org, 79228 <at> debbugs.gnu.org
> >>
> >> On Mon, Sep 1, 2025, 3:52 AM Andrea Corallo <acorallo <at> gnu.org> wrote:
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> 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?
> Thus the native compilation can happen in a non-main thread.
So step 3 is not necessary?
This bug report was last modified 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.