From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Sat, 15 Oct 2022 10:18:33 -0400 Message-ID: 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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a55ade05eb136b43" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22521"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Lars Ingebrigtsen , Stefan Monnier , liliana.prikler@gmail.com, rlb@defaultvalue.org, emacs-devel To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 15 16:19:31 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 1oji0g-0005fC-PV for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 16:19:30 +0200 Original-Received: from localhost ([::1]:44928 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oji0f-0003JF-Es for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Oct 2022 10:19:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60680) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oji02-0002eW-ER for emacs-devel@gnu.org; Sat, 15 Oct 2022 10:18:50 -0400 Original-Received: from mail-pg1-x52b.google.com ([2607:f8b0:4864:20::52b]:46993) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oji00-00038o-Gg; Sat, 15 Oct 2022 10:18:50 -0400 Original-Received: by mail-pg1-x52b.google.com with SMTP id 78so6706125pgb.13; Sat, 15 Oct 2022 07:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tOSECCgqVZSnBLlX0CxvEMEkSMHvaRxZTaBbXW+wnvE=; b=eNrqEe03BhLyXF1Pit/adyd7vBRLHraxu6/sG5EBTF8od9uJQ8NaylwijkcJeYaNM9 gnSleVYa0LWpl3xrFsZBfyy38ap5kCdux7B+FIZ0M46gv4DxkPTl8AbjQHK9aymRlQJP mtuTDQ0lrTUKjMxNksusQ/jyYXEAI1W1MD3IzldJ3aE42X9cmAH4dgxgyBs9AwORlqy3 XGnn3eYg8d/ZVB6PH7eCzcOYAYHO+fcsiwGrZx1MMIm0VcnEjaNJGwgIMIsHIKZnOcS0 mJ0RAWbxsZQ8Yxk9tUZY30bjgSllZ6/lS/aDYacOmrh9BuYFTAAy3JaAKiT0ZuK22Fcs EavQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tOSECCgqVZSnBLlX0CxvEMEkSMHvaRxZTaBbXW+wnvE=; b=TC/95VUGdb7znpMgoXld8u6JlUcAYgyyQYjKfrSHnBvuTyBHRC3EbZJk4SDrcSTuCZ R5yba4627rh1zJXONbq71JiOEmOa3uNGyXtqiL8QefgqfZhpe3EJEq+lKxTn6gpuM8/5 fl0eT5T8mgU2WdksUXIXhwA76vpYw3BflFFN2btAntWNh0RSn+TUVXrhkeLchjJn3TFF P8u4JHO0QTh/m762nh/jrPVKoD1up6mV6oksDmUMaShYdRkEWKKKCIXAhWbUYLbSfW0e CYNBYtAPzynNehDMdusUK920LujoSeKxtt0sUm1rLEePxvF+EKQbUJmDFIUY6Tj7yXJT zC5w== X-Gm-Message-State: ACrzQf1T1Z/MR8mtW4b6r778q8Uk0hkwImXwv4slHeX89lh1GWgNcQhi JXh+2/tE79CFNIn7gXp6aPLSd71V5dOadmRZg8HSirRBHJg= X-Google-Smtp-Source: AMsMyM78DY7oQG2T2AXZ2QBvR9vFRpOitxVsULHZjpqp10vPrFK4WWtFIYKOpHpj1k/R/Q1/NFcdphpjEOJoyOJnuzE= X-Received: by 2002:a63:d551:0:b0:452:87e0:73d5 with SMTP id v17-20020a63d551000000b0045287e073d5mr2714719pgi.488.1665843526455; Sat, 15 Oct 2022 07:18:46 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::52b; envelope-from=owinebar@gmail.com; helo=mail-pg1-x52b.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:297779 Archived-At: --000000000000a55ade05eb136b43 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 14, 2022, 7:22 PM Andrea Corallo wrote: > Eli Zaretskii writes: > > >> From: Lars Ingebrigtsen > >> Cc: Stefan Monnier , > liliana.prikler@gmail.com, > >> rlb@defaultvalue.org, emacs-devel@gnu.org, Andrea Corallo < > akrl@sdf.org> > >> Date: Thu, 13 Oct 2022 22:57:51 +0200 > >> > >> Eli Zaretskii writes: > >> > >> > No, it should not happen, because async JIT compilation processes run > >> > Emacs in batch mode, and async compilation is disabled in batch mode > >> > (for this very reason). > >> > >> As we've covered many times recently -- yes, but no. > >> > >> .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? > > 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. The cleanest way would be to prepare a dump file specifically for compiling that is known to work, then use that for the async compiler job with any required settings passed in the command line. This would make the system robust when the system dump file is not limited to just the standard build. Lynn --000000000000a55ade05eb136b43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 14, 2022, 7:22 PM Andrea Corallo <akrl@sdf.org> wrote:
Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,=C2= =A0 liliana.prikler@gmail.com,
>>=C2=A0 =C2=A0rlb@defaultvalue.org,=C2=A0 emacs-devel@gnu.org= , Andrea Corallo <akrl@sdf.org>
>> Date: Thu, 13 Oct 2022 22:57:51 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > No, it should not happen, because async JIT compilation proce= sses run
>> > Emacs in batch mode, and async compilation is disabled in bat= ch mode
>> > (for this very reason).
>>
>> As we've covered many times recently -- yes, but no.
>>
>> .elc -> .eln generation is off, but trampolines are on, and com= p.el
>> forks an Emacs to generate those, too, I think?=C2=A0 So if the fo= rked 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?

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

The cleanest way would be to prepare a dump file specifically for comp= iling that is known to work, then use that for the async compiler job with = any required settings passed in the command line.=C2=A0 This would make the= system robust when the system dump file is not limited to just the standar= d build.

Lynn

--000000000000a55ade05eb136b43--