bug#41242: Port feature/native-comp to Windows

[Nicolas Bértolo]

> 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@gnu.org>) escribió:

> From: Nicolas Bértolo <nicolasbertolo@gmail.com>
> Date: Sat, 16 May 2020 13:12:20 -0300
> Cc: Andrea Corallo <akrl@sdf.org>, 41242@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.