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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 14 May 2020 22:00:19 +0300

> From: Nicolas Bértolo <[email-masked]>
> Date: Thu, 14 May 2020 15:40:28 -0300
> Cc: Eli Zaretskii <[email-masked]>, [email-masked]
> 
> * 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.

How can Emacs2 realize that foo.eln was renamed?

> 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 will have to tell users not to do that on Windows.