Re: Deferring native compilation finalization until idle

On Sat, Jul 25, 2026 at 12:32 PM Eli Zaretskii <[email protected]> wrote:

> > Date: Sat, 25 Jul 2026 15:56:52 +0000
> > From: "Aaron Jensen" <[email protected]>
> > Cc: Stéphane Marks <[email protected]>, "Eli Zaretskii"
> >  <[email protected]>, [email protected], [email protected],
> [email protected]
> >
> > I'm afraid that the notion that this is a CPU saturation problem is
> demonstrably false as well.
>
> If the reason is macOS validation of the *.eln files being loaded,
> then CPU saturation is not relevant at all: the validation most
> probably runs in the same thread as the one Emacs uses to load the*.eln
> files, because the validation most probably intercepts the system
> calls that load shared libraries.
>

Right.  It is tantamount to virus scanners that interpose in system calls.

> My suggested change was to move the first load to actually be
> asynchronous.
>
> That would mean Emacs will be unable to use the native code until it
> is loaded at some future time.  IOW, this comes with some performance
> hit, which the current code avoids.  Therefore, I would like to
> introduce this complication only if the problem is wide enough, and
> even then only on macOS.  Please be more patient.
>
> >    codesign --force --sign - \
> >        --entitlements macos-disable-library-validation.entitlements \
> >        src/emacs
> >
> >  Are you using that?
> >
> > If the Jimeh build uses this, it didn't work for me. Regardless, this is
> exactly the thing that disables the security
> > check macOS is doing. It is certainly a "workaround". And it does, in
> fact, prevent the stutter. If you're doing this
> > (or your build is) and you're not seeing problems, that explains it
> completely. It seems somewhat strange to say
> > "I'm already doing the workaround and I don't have the problem!", so I'm
> not sure exactly what you're getting at
> > here. Without disabling validation, this *is a main thread problem*
> because the entirety of macOS compilation +
> > validation is *not* done asynchronously.
>
> TBH, I don't understand why that validation is need for *.eln files.
> Those are compiled on your machine, so what validation is necessary?
> It's not like you download unknown binaries from somewhere.
>

Per
https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.security.cs.disable-library-validation?language=objc

"The Hardened Runtime enables library validation by default. This
security-hardening feature prevents a program from loading frameworks,
plug-ins, or libraries unless they’re either signed by Apple or signed with
the same Team ID as the main executable."

This includes the native modules produced by libgccjit.  I suppose that
unless and until libgccjit binaries can be signed as the bundle is signed
(assuming people are running from a bundle), scanning will always be done
without the OS-level opt out.