From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Sat, 15 Oct 2022 10:04:45 +0300 Message-ID: <83mt9x7ek2.fsf@gnu.org> References: <87ill8paw7.fsf@trouble.defaultvalue.org> <83o7uzivey.fsf@gnu.org> <3ac9d2b9632f75018327a1bcde0c373f152c404a.camel@gmail.com> <835ygob7ja.fsf@gnu.org> <8335bra2rl.fsf@gnu.org> <87ilkncugg.fsf@gnus.org> <83zgdz7x8u.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38113"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, monnier@iro.umontreal.ca, liliana.prikler@gmail.com, rlb@defaultvalue.org, emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 15 09:06:02 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ojbFC-0009fJ-DV for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 09:06:02 +0200 Original-Received: from localhost ([::1]:35402 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojbFA-0003pK-Nf for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 03:06:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57722) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojbEA-000389-G8 for emacs-devel@gnu.org; Sat, 15 Oct 2022 03:04:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55540) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojbE9-0006Fl-J4; Sat, 15 Oct 2022 03:04:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=KDFNgT48qhk5HQz5DICWEeNXTX5BoSniPExAq9oGRe4=; b=Hl0DxMIWmr6U qlmVYXF1/WomqeTmRGoTB9c1RfjgDZE69LQOmHItk5KnflGBYtdqs6b9vzy7d9Xn+eygr68XTB9x6 JpYTtPHc5aE3v/3iMdWretyAiOx6RCY1aPbKDGyJr+K5lJ/W+MOkP9irbRwdJOCMRfQ8DTvCE62l+ UkXIzoW+afCVTY7126uPzNbj56yQ6sh6+0RnhbHuLzEr9YjFrkCQZFKERA5lexnGWipK2xfiCX0dR t+4mZXkCenDINeDzggzBfbnpXlFvTCNffQFKun5EBB1Z939pFCKiDA14AYZmxVv4hbHmBuHrP+d2u mOe32AaL4vyfObh6K8Ia1Q==; Original-Received: from [87.69.77.57] (port=3577 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojbE9-0001mg-17; Sat, 15 Oct 2022 03:04:57 -0400 In-Reply-To: (message from Andrea Corallo on Fri, 14 Oct 2022 23:20:43 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:297759 Archived-At: > From: Andrea Corallo > Cc: Lars Ingebrigtsen , 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 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?