GNU bug report logs - #41242
Port feature/native-comp to Windows

Previous Next

Package: emacs;

Reported by: Nicolas Bértolo <nicolasbertolo <at> gmail.com>

Date: Wed, 13 May 2020 19:28:01 UTC

Severity: wishlist

Done: Andrea Corallo <akrl <at> sdf.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 41242 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: bug#41242: Port feature/native-comp to Windows
Date: Sat, 16 May 2020 13:31:41 -0300
[Message part 1 (text/plain, inline)]
> No, on Posix systems we can delete the file, and it will be actually
> deleted when its last handle is closed.  I believe this works with
> shared libraries as well.

Do we actually do it? I don't think so. I don't even know where exactly
that check should be. Maybe `eval-buffer`?

> It's the same problem, yes.  Just a slightly different use case, which
> could therefore have different probabilities for some aspects.  For
> example, the probability of the same .el file being recompiled from
> two separate sessions is relatively small, except when you consider
> the "make -jN" use case.

The probability of two Emacs recompiling the same file in the "make -jN"
case is
0. That is because the build system tells each Emacs to compile one and
only one
file that is passed as a parameter. See #41329 for a bug related to this.

The case of two Emacs sessions recompiling the same file at the same time is
actually a problem.

We could implement the following algorithm:

- Have libgccjit write the .eln to a temporary name in the destination
folder.

- While "foo.eln" exists:
  - Rename it to "foo.eln.oldN".
  - Move the new .eln file to "foo.eln"

Nicolas


El sáb., 16 may. 2020 a las 13:19, Eli Zaretskii (<eliz <at> gnu.org>) escribió:

> > From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
> > Date: Sat, 16 May 2020 13:12:20 -0300
> > Cc: Andrea Corallo <akrl <at> sdf.org>, 41242 <at> debbugs.gnu.org
> >
> > > I'm not sure I understand why we are talking only about package.el.
> > > Wouldn't the same problem happen if the user recompiles a .el file for
> > > which a .eln file already exists and is loaded into the session?
> >
> > True, right now the .eln would not be removed. Not even in Posix.
>
> No, on Posix systems we can delete the file, and it will be actually
> deleted when its last handle is closed.  I believe this works with
> shared libraries as well.
>
> > > And
> > > similarly when Emacs is being built and all the *.el files are being
> > > compiled or recompiled, sometimes by several Emacs processes running
> > > in parallel via "make -jN"
> >
> > Help me understand. Are you referring to the case where a developer
> changes
> > an .el file for which an .eln file (now outdated) already exists?
>
> No, I mean building Emacs with "make -j10 bootstrap".
>
> > I think fixing the case above will fix this one.
>
> It's the same problem, yes.  Just a slightly different use case, which
> could therefore have different probabilities for some aspects.  For
> example, the probability of the same .el file being recompiled from
> two separate sessions is relatively small, except when you consider
> the "make -jN" use case.
>
[Message part 2 (text/html, inline)]

This bug report was last modified 5 years and 41 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.