[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: using finalizers
From: |
Eli Zaretskii |
Subject: |
Re: using finalizers |
Date: |
Sat, 01 Jan 2022 20:20:22 +0200 |
> 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).
Re: using finalizers, Tomas Hlavaty, 2022/01/01
Re: using finalizers, Tomas Hlavaty, 2022/01/01