Re: using finalizers

[Eli Zaretskii <eliz@gnu.org>]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 31 Dec 2021 10:31:02 +0100
> 
> On Fri 31 Dec 2021 at 09:50, Eli Zaretskii <eliz@gnu.org> wrote:
> > I think that the assumption that a call to garbage-collect will
> > necessarily call the finalizer is also problematic: there's usually no
> > simple way to make sure there are no references left to the object,
> 
> This breaks my expectations.  Could you explain that more?

The main aspect to have in mind is that your Lisp code has no direct
control on when a given Lisp object is no longer referenced by any
other live object.  And even if you take care to do that on the Lisp
level (something that is notoriously hard, if possible), GC also scans
the C stack for anything that looks like a reference to a Lisp object,
and marks any such objects as not (yet) collectible.  And your Lisp
program has no control on what's on the C stack.

> Does it mean that for example thunk-delay leaks even though it releases
> the reference to the body thunk?

If GC doesn't collect an object right away, it doesn't yet mean we
have a leak.  As long as the object is collected "eventually", we are
fine.

> Does it mean that setting reference to nil in order to dispose an object
> (as in my original example) is futile?

It doesn't necessarily guarantee GC will collect the object, yes.

> > and GC could have its own ideas when to actually garbage-collect an
> > object.
> 
> I don't think timing is an issue.  I think the expectation from gc is
> that it collects the object "eventually as needed".

That does happen, but you seem to expect more: you expect that the
object is collected as soon as you do something in Lisp to break the
binding between the object and the variable that was bound to it.