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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
Cc: 41242 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: bug#41242: Port feature/native-comp to Windows
Date: Sat, 16 May 2020 19:42:27 +0300

> From: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
> Date: Sat, 16 May 2020 13:31:41 -0300
> Cc: Andrea Corallo <akrl <at> sdf.org>, 41242 <at> debbugs.gnu.org
> 
> > 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`?

I'm not sure I understand what check did you have in mind.

> > 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.

Sorry, I meant the probability of one session compiling a file while
another uses it.

> 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"

Something like that, yes.

Previous Next

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