Re: using finalizers

[Stefan Monnier <monnier@iro.umontreal.ca>]

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