From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#41242: Port feature/native-comp to Windows Date: Thu, 14 May 2020 17:32:28 +0300 Message-ID: <834ksi60zn.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="13828"; mail-complaints-to="usenet@ciao.gmane.io" Cc: nicolasbertolo@gmail.com, 41242@debbugs.gnu.org To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 14 16:56:04 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jZFHI-0003Sq-62 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 May 2020 16:56:04 +0200 Original-Received: from localhost ([::1]:40464 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZFHH-0001jq-4R for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 May 2020 10:56:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41378) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZEv1-0007x4-KP for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 10:33:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51051) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jZEv1-0000d4-8d for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 10:33:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jZEv0-0005ac-3t for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 10:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2020 14:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41242 X-GNU-PR-Package: emacs Original-Received: via spool by 41242-submit@debbugs.gnu.org id=B41242.158946677221464 (code B ref 41242); Thu, 14 May 2020 14:33:02 +0000 Original-Received: (at 41242) by debbugs.gnu.org; 14 May 2020 14:32:52 +0000 Original-Received: from localhost ([127.0.0.1]:34364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZEup-0005a7-JE for submit@debbugs.gnu.org; Thu, 14 May 2020 10:32:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38374) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZEuo-0005Zs-I9 for 41242@debbugs.gnu.org; Thu, 14 May 2020 10:32:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34112) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZEui-0000bD-9a; Thu, 14 May 2020 10:32:44 -0400 Original-Received: from [176.228.60.248] (port=4735 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jZEuh-0005a8-At; Thu, 14 May 2020 10:32:43 -0400 In-Reply-To: (message from Andrea Corallo on Thu, 14 May 2020 11:17:11 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:180211 Archived-At: > From: Andrea Corallo > Cc: bug-gnu-emacs@gnu.org, > Nicolas Bértolo > , > 41242@debbugs.gnu.org > Date: Thu, 14 May 2020 11:17:11 +0000 > > > Windows doesn't let you delete a shared library that's loaded by a > > process, but it does let you rename it. So I think the solution would > > be to rename the .eln file to something like .eln.old, and then let > > the GC driven unload machinery to delete that old file. > > Do we have guarantees that each object is collected before Emacs is > eventually closed? I thought is not the case. I don't know enough about the "GC driven unload" you mentioned, but if that is not bulletproof enough, we could add a kill-emacs hook to take care of this. And if push comes to shove, we could use a Windows API that causes a file to be deleted when the last handle on it is closed, but that would add complexity, so I think we should try easier ways first. > > Btw, what happens if more than one Emacs session have the same .eln file loaded, and one of them wants to recompile it? > > Now to avoid this problem we always delete the file before recompiling. But that's unportable, and won't work on Windows, for the same reasons as the issue we are discussing here. Or am I missing something?