GNU bug report logs - #41242
Port feature/native-comp to Windows

Previous Next

Full log

Message #110 received at 41242 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
Cc: 41242 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#41242: Port feature/native-comp to Windows
Date: Thu, 14 May 2020 22:00:19 +0300

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.