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

Previous Next

Full log

Message #50 received at 41242 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: nicolasbertolo <at> gmail.com, 41242 <at> debbugs.gnu.org
Subject: Re: bug#41242: Port feature/native-comp to Windows
Date: Thu, 14 May 2020 17:32:28 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: bug-gnu-emacs <at> gnu.org,
>         Nicolas Bértolo
>  <nicolasbertolo <at> gmail.com>,
>         41242 <at> debbugs.gnu.org
> Date: Thu, 14 May 2020 11:17:11 +0000
> 
> > Windows doesn't let you delete a shared library that's loaded by a
> > process, but it does let you rename it.  So I think the solution would
> > be to rename the .eln file to something like .eln.old, and then let
> > the GC driven unload machinery to delete that old file.
> 
> Do we have guarantees that each object is collected before Emacs is
> eventually closed?  I thought is not the case.

I don't know enough about the "GC driven unload" you mentioned, but if
that is not bulletproof enough, we could add a kill-emacs hook to take
care of this.  And if push comes to shove, we could use a Windows API
that causes a file to be deleted when the last handle on it is closed,
but that would add complexity, so I think we should try easier ways
first.

> > Btw, what happens if more than one Emacs session have the same .eln file loaded, and one of them wants to recompile it?
> 
> Now to avoid this problem we always delete the file before recompiling.

But that's unportable, and won't work on Windows, for the same reasons
as the issue we are discussing here.  Or am I missing something?

Previous Next

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