[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41242: Port feature/native-comp to Windows
From: |
Nicolas Bértolo |
Subject: |
bug#41242: Port feature/native-comp to Windows |
Date: |
Thu, 14 May 2020 14:35:36 -0300 |
> Why do you need to check if it's renamed? Just rename always.
You need to see if the file has been renamed because someone needs
to delete the file
> It is not good to move to $TEMP because that one could be on a
> different volume, and Windows won't let you do that with a DLL that is
> loaded into a process.
Touché.
El jue., 14 may. 2020 a las 14:28, Eli Zaretskii (<eliz@gnu.org>) escribió:
>
> > From: Nicolas Bértolo <nicolasbertolo@gmail.com>
> > Date: Thu, 14 May 2020 13:50:48 -0300
> > Cc: Eli Zaretskii <eliz@gnu.org>, 41242@debbugs.gnu.org
> >
> > 1) Call `native-comp-unload`.
> >
> > 2) This should inspect the eln file and put all the subrs defined in it on a
> > list. This should also copy the original bytecode from the eln file and
> > store it
> > somewhere.
> >
> > 3) Then `garbage-collect` is called. This should find all references to the
> > subrs in the list and swap them atomically for references to functions
> > from the bytecode.
> >
> > 4) After the previous step the GC should be able to collect the DLL handle
> > knowing that no references to it remain.
> >
> > What do you think?
>
> Do we really need this complexity?
>
> > > 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.
> >
> > But someone needs to delete the old eln file. Let's say that we use
> > GetModuleFileNameA() to know if another Emacs instance has decided to
> > rename the
> > eln file and then we delete it on close if its suffix is ".eln.old".
> >
> > This algorithm has a big race condition though. If Emacs1 renames the file
> > after
> > Emacs2 has checked that it has not been renamed, then the file won't be
> > deleted.
>
> Why do you need to check if it's renamed? Just rename always.
>
> > If we put the "old eln" in the $TEMP folder this may not be a big issue
> > though.
>
> It is not good to move to $TEMP because that one could be on a
> different volume, and Windows won't let you do that with a DLL that is
> loaded into a process.
- 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, 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 <=
- 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
- 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, Nicolas Bértolo, 2020/05/14