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

Previous Next

Full log

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

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

> Here we are really complexifying a problem that is not.  IMO renaming
> and having a list to do the clean-up are sufficient tools to solve it.

You're right. I just think that renaming and a list do not guarantee that we
always delete the files when we should.

Consider this case:

* 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.

That is the good case.

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 could add a "GC" step to `load`, where it tries to find stale .eln.old
files and removes them.

Nicolas.

El jue., 14 may. 2020 a las 15:13, Andrea Corallo (<akrl <at> sdf.org>) escribió:
>
> Nicolas Bértolo <nicolasbertolo <at> gmail.com> writes:
>
> >> 1- eln files do not retain the orginal function bytecode.
> >
> > That should be easy to change.
>
> Sure but we don't want to do that because there's no reason to bloat the
> eln.
>
> >> in any point of the code you can get the symbol-function of a defined
> >    function and leak it everywhere.
> >
> > This is why I said the GC should do it. It should be able to find all
> > references.
>
> Yes but I can't *remove* objects that are referenced niether swap them.
> See below.
>
> >> We can't technically "swap" functions definitions, the best we do is just
> >> redefine them that is set a certain symbol-function (what late load does).
> >
> > When the GC finds a Lisp_Object that points to a subr we want to unload,
> > it should replace it with one that points to its bytecode equivalent version.
>
> No it cannot, if an object has been tested to say satisfy a predicate
> you cannot change it for another one.  It would break tons of code and
> make the system totally un-debuggable.
>
> >> Even worst the function you want to remove could be active in the stack!
> >
> > You are right. I hadn't considered this. It can still be done, but would need to
> > wait until the function finishes.
>
> Yes, but when are all functions you want to get rid deactivated?
>
> Here we are really complexifying a problem that is not.  IMO renaming
> and having a list to do the clean-up are sufficient tools to solve it.
>
> --
> akrl <at> sdf.org

Previous Next

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