[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: using finalizers
From: |
Stefan Monnier |
Subject: |
Re: using finalizers |
Date: |
Sat, 01 Jan 2022 15:55:38 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
>> 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.
A common problem during manual experimentation is to have the offending
value stashed in `values`.
>> 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?
Calling `garbage-collect` should usually work well enough for tests
(tho this may have to be tweaked if/when we get a fancier GC), tho
there's always the risk that some bitpattern somewhere inside the stack
happens to look like a pointer to your finalizer (or an object that
transitively references it), so no I don't know of a way to *reliably*
get a finalizer to run.
You can minimize the risk of a bitpattern getting in the way by trying
to trigger a GC at a point where the C stack is as small as possible,
but it still can't rule out the problem completely.
Stefan
Re: using finalizers, Tomas Hlavaty, 2022/01/01
Re: using finalizers, Tomas Hlavaty, 2022/01/01
- Re: using finalizers, Eli Zaretskii, 2022/01/02
- Re: using finalizers, Tomas Hlavaty, 2022/01/02
- Re: using finalizers, Eli Zaretskii, 2022/01/02
- Re: using finalizers, Tomas Hlavaty, 2022/01/02
- Re: using finalizers, Eli Zaretskii, 2022/01/02
- Re: using finalizers, Eli Zaretskii, 2022/01/02