[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41242: Port feature/native-comp to Windows
From: |
Andrea Corallo |
Subject: |
bug#41242: Port feature/native-comp to Windows |
Date: |
Thu, 14 May 2020 15:03:08 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: bug-gnu-emacs@gnu.org,
>> Nicolas Bértolo
>> <nicolasbertolo@gmail.com>,
>> 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.
Now simply when the compilation unit object is collected, the handle is
closed. The compilation unit is collected when is not reachable by any
of the functions defined into.
Loading a new compilation unit B that redefines the same functions
defined by A does not guarantees much, some of the old definitions of A
could be still in use somewhere, in that case A will not be collected.
So yeah I think we need a specific mechanism (kill-emacs hook as you
suggest) to do the cleanup when Emacs goes down.
>> > 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?
No you are right, I don't use Windows since forever, I discovered from
this thread is not portable. I guess we'll need to rename also here.
Andrea
--
akrl@sdf.org
- bug#41242: Port feature/native-comp to Windows, (continued)
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/13
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/14
- bug#41242: Port feature/native-comp to Windows,
Andrea Corallo <=
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Nicolas Bértolo, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Achim Gratz, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Eli Zaretskii, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/14
- bug#41242: Port feature/native-comp to Windows, Andrea Corallo, 2020/05/14