emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suppressing native compilation (short and long term)


From: Eli Zaretskii
Subject: Re: Suppressing native compilation (short and long term)
Date: Sat, 15 Oct 2022 10:04:45 +0300

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, monnier@iro.umontreal.ca,
>         liliana.prikler@gmail.com, rlb@defaultvalue.org, emacs-devel@gnu.org
> Date: Fri, 14 Oct 2022 23:20:43 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> .elc -> .eln generation is off, but trampolines are on, and comp.el
> >> forks an Emacs to generate those, too, I think?  So if the forked Emacs
> >> also needs to generate the same trampoline, you have an infinite
> >> recursion fork bomb.
> >
> > Andrea, how can we prevent that?
> 
> Dumb question: can't we just run the spawned compilation processes with
> --no-site-file?

I don't think I understand how --no-site-file could help.  Are you
assuming that such advises could only come from sit-init files?  If
so, I'm sure they could come from other sources, or what am I missing?

> Other option is to break circularity with an ad-hoc global variable set
> in the spawned process.  I've a cooked patch for that but no energy left
> to test it tonight.  If that's the preferred way I can test and push it
> tomorrow.

Maybe it's preferable, but I'm not sure the idea of the change I get
from your short description is what you really meant.  Can you tell
more about that?  What ad-hoc variables did you have in mind, and how
would we use them in this case to prevent infinite forking of
sub-processes?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]