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

[Andrea Corallo]

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

>> Here we are really complexifying a problem that is not.  IMO renaming
>> and having a list to do the clean-up are sufficient tools to solve it.
>
> You're right. I just think that renaming and a list do not guarantee that we
> always delete the files when we should.
>
> Consider this case:
>
> * Emacs1 and Emacs2 are two Emacs instances that load the
> same foo.eln file.
>
> * Emacs1 decides to recompile foo.el. To do that it renames foo.eln to
>   foo.eln.old. It creates a new foo.eln and tries to delete foo.eln.old. It
>   fails because Emacs2 has an open handle to it.
>
> * When Emacs2 closes it realizes that foo.eln has been renamed to foo.eln.old
>   and deletes it.
>
> That is the good case.
>
> If we are unlucky this is what may happen:
>
> * Emacs2 begins to close. It checks that foo.eln has not been renamed. 
> Therefore
>   it does not delete it. But it does not call FreeLibrary yet.
>
> * Emacs1 renames foo.eln to foo.eln.old. It tries to delete it but fails since
>   Emacs2 has an open handle.
>
> * Emacs2 finally calls FreeLibrary() and closes.
>
> In this case we are left over with a stale foo.eln.old. I don't think we can
> have a race free algorithm.
>
> We could add a "GC" step to `load`, where it tries to find stale .eln.old
> files and removes them.
>
> Nicolas.

I see.  But I suspect it could work just if each Emacs sessions depose a
file to signal is activelly using a certain .eln.

The last session can retrive the current filename of the handle and
delete it.

Do you think it works?

-- 
akrl@sdf.org