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

[Andrea Corallo <akrl@sdf.org>]

Nicolas Bértolo <nicolasbertolo@gmail.com> writes:

>> 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.
>
> I was thinking about something like this:
>
> 1) Call `native-comp-unload`.
>
> 2) This should inspect the eln file and put all the subrs defined in it on a
> list. This should also copy the original bytecode from the eln file and store it
> somewhere.
>
> 3) Then `garbage-collect` is called. This should find all references to the
> subrs in the list and swap them atomically for references to functions
> from the bytecode.
>
> 4) After the previous step the GC should be able to collect the DLL handle
> knowing that no references to it remain.
>
> What do you think?

It can't work for the following reasons:

1- eln files do not retain the orginal function bytecode.

2- in any point of the code you can get the symbol-function of a defined
   function and leak it everywhere.  We can't technically "swap"
   functions definitions, the best we do is just redefine them that is
   set a certain symbol-function (what late load does).  The old
   definitions can always still be used if the referennce is still
   present somewhere.  Even worst the function you want to remove could
   be active in the stack!

One option would be to add a field into the compilation unit object like
'pending_for_removal', each time any of this is unloaded by GC the file
is removed if the field suggests that.  At the very last when Emacs is
closing we go through all the compilation units and remove the files
that are still pending.

>> 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.
>
> But someone needs to delete the old eln file. Let's say that we use
> GetModuleFileNameA() to know if another Emacs instance has decided to rename the
> eln file and then we delete it on close if its suffix is ".eln.old".
>
> This algorithm has a big race condition though. If Emacs1 renames the file after
> Emacs2 has checked that it has not been renamed, then the file won't be deleted.
> If we put the "old eln" in the $TEMP folder this may not be a big issue though.

Yes renaming for me here was moving into a temporary folder.

This could be a very simple option also for the first problem if we
accept we can leave some file there from time to time.

  Andrea

-- 
akrl@sdf.org