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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

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

Now simply when the compilation unit object is collected, the handle is
closed.  The compilation unit is collected when is not reachable by any
of the functions defined into.

Loading a new compilation unit B that redefines the same functions
defined by A does not guarantees much, some of the old definitions of A
could be still in use somewhere, in that case A will not be collected.

So yeah I think we need a specific mechanism (kill-emacs hook as you
suggest) to do the cleanup when Emacs goes down.

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

No you are right, I don't use Windows since forever, I discovered from
this thread is not portable.  I guess we'll need to rename also here.

  Andrea

--
akrl@sdf.org