unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Daniel Colascione" <dancol@dancol.org>
To: "Eli Zaretskii" <eliz@gnu.org>
Cc: Daniel Colascione <dancol@dancol.org>, emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master 1072155: Avoid duplicate entries in process-environment after re-dumping
Date: Tue, 2 Apr 2019 13:11:53 -0700	[thread overview]
Message-ID: <369aae77db760bfe079e47254470001d.squirrel@dancol.org> (raw)
In-Reply-To: <834l7gfbxn.fsf@gnu.org>

>> Date: Tue, 2 Apr 2019 12:02:55 -0700
>> From: "Daniel Colascione" <dancol@dancol.org>
>>
>> > +  /* 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.
>
>





  reply	other threads:[~2019-04-02 20:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190321155613.6127.22574@vcs0.savannah.gnu.org>
     [not found] ` <20190321155614.E6343209B2@vcs0.savannah.gnu.org>
2019-04-02 19:02   ` [Emacs-diffs] master 1072155: Avoid duplicate entries in process-environment after re-dumping Daniel Colascione
2019-04-02 19:24     ` Eli Zaretskii
2019-04-02 20:11       ` Daniel Colascione [this message]
2019-04-03  9:22         ` Eli Zaretskii
2019-04-03 16:58           ` Daniel Colascione
2019-04-03 17:32             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=369aae77db760bfe079e47254470001d.squirrel@dancol.org \
    --to=dancol@dancol.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).