Re: using finalizers

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: andpuke@foxmail.com, emacs-devel@gnu.org
> Date: Sat, 01 Jan 2022 18:58:01 +0100
> 
> On Fri 31 Dec 2021 at 14:27, Eli Zaretskii <eliz@gnu.org> wrote:
> > 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.
> 
> No, that's not what I expect.  I even said that.  What I meant is that I
> did not expect some other code not under my control to keep references
> to the object forever preventing gc to run the finalizer eventually,
> which is how I understood your reply.

Not "forever", of course, but depending on the program a reference to
an object could live for quite some time.  Having a reference on the C
stack is the most sinister of these.

> On another note, I see that finalizers are rarely used and tested:
> 
> ./test/src/alloc-tests.el33:  (should (equal (type-of (make-finalizer nil)) 
> 'finalizer)))
> ./lisp/emacs-lisp/generator.el642:                      (make-finalizer
> 
> For example the cps-generate-evaluator function has 70 lines and it is
> not obvious to me, that the use of finalizer is not buggy.
> 
> Do you have an advice, how are programmers supposed to test finalizers?
> 
> My original issue did not run the finalizer because of a bug in my use
> of letrec.  Unless there is a good way to actually trigger the
> finalizer, there is no good way to test such code paths.  Or shall the
> programmers just hope for the best?

I hope Stefan could answer that, but it sounds like he doesn't
understand the issue you are describing (and neither do I, frankly).