From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Daniel Colascione" Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 1072155: Avoid duplicate entries in process-environment after re-dumping Date: Tue, 2 Apr 2019 13:11:53 -0700 Message-ID: <369aae77db760bfe079e47254470001d.squirrel@dancol.org> References: <20190321155613.6127.22574@vcs0.savannah.gnu.org> <20190321155614.E6343209B2@vcs0.savannah.gnu.org> <892097f7bc3f5e0ac88d31c60e0bed59.squirrel@dancol.org> <834l7gfbxn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="115702"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: SquirrelMail/1.4.23 [SVN] Cc: Daniel Colascione , emacs-devel@gnu.org To: "Eli Zaretskii" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 02 22:12:07 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hBPlO-000TyF-Bo for ged-emacs-devel@m.gmane.org; Tue, 02 Apr 2019 22:12:07 +0200 Original-Received: from localhost ([127.0.0.1]:59516 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBPlN-0006vo-8v for ged-emacs-devel@m.gmane.org; Tue, 02 Apr 2019 16:12:05 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBPlG-0006vT-Je for emacs-devel@gnu.org; Tue, 02 Apr 2019 16:11:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBPlF-0000IC-Nn for emacs-devel@gnu.org; Tue, 02 Apr 2019 16:11:58 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:45888) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hBPlD-0000Gx-61; Tue, 02 Apr 2019 16:11:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=PVOOGvAR5kp66lY1ZB+EU+GuyXNG/CpdU9P0Q3xcBp4=; b=PEWYpaVloBiPLOAY5eELHl1/GffNtcK8u63ADf2CjuWgjx/EHFDVFR/gXBygn3KA7FUl9D59R48/Bj8g6vnHOx404geOTh6Y7QiiYzVVUwxYKl5iXcP6dVq4tpGkxW4/MrjxFgwblzuclAMZfahmSWm/Qb9TBPAvQpZ0WCfgOv/zDWh49OgVSfHhsIhcYcXyP8syLmU57dIEC1rfFVkpyXFIG1NLQPlVT3C0h/Vhq/rC8KS0NtGy+xnFQ0a/l3RwzNo3njoP2sNpfDO6qFuxXjrrPSnh5knD01UA7wZdADH5s9tpw4F58XYswGvVnP+xZHgr3lRITelQ7VsNrYhCpA==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBPlB-0006Q8-6g; Tue, 02 Apr 2019 13:11:53 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Tue, 2 Apr 2019 13:11:53 -0700 In-Reply-To: <834l7gfbxn.fsf@gnu.org> X-Priority: 3 (Normal) Importance: Normal X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:234897 Archived-At: >> Date: Tue, 2 Apr 2019 12:02:55 -0700 >> From: "Daniel Colascione" >> >> > + /* Reset process-environment -- this is for when they re-dump a >> > + pdump-restored emacs, since set_initial_environment wants always >> > + to cons it from scratch. */ >> > + Vprocess_environment = Qnil; >> >> Don't we want to reset process-environment to its old value in >> dump_unwind_cleanup? > > You are thinking about re-dumping from an interactive session? Yes > In > that case, probably yes. But currently we only support dumping from > batch sessions, and in that case I don't see a need to restore > process-environment, am I missing something? We "support" dumping only from dedicated batch instances in that for now we should consider only bugs in that use case release-blocking, but I don't want to gratuitously break other use cases like dumping interactive sessions without killing them, since these use cases are meant to work and we'll give them the same level of support someday soon. > >> > + garbage_collect (); >> > + >> > CHECK_STRING (filename); >> > filename = Fexpand_file_name (filename, Qnil); >> > filename = ENCODE_FILE (filename); >> >> Does it make sense to move this chunk before the >> garbage-collect-until-we-run-all-finalizers loop above? That way, we'd >> run >> one fewer GC. > > Probably. I just wanted to do this as close to the actual dumping as > possible, but maybe it's not that important. > >