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

[Eli Zaretskii]

> From: Nicolas Bértolo <nicolasbertolo@gmail.com>
> Date: Thu, 14 May 2020 15:40:28 -0300
> Cc: Eli Zaretskii <eliz@gnu.org>, 41242@debbugs.gnu.org
> 
> * 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.