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

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: bug-gnu-emacs@gnu.org,
>         Nicolas Bértolo
>  <nicolasbertolo@gmail.com>,
>         41242@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?