bug#26503: Local variables reclaimed early vs. finalizers

[ludo@gnu.org (Ludovic Courtès)]

Andy Wingo <wingo@pobox.com> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Consider this code:
>>
>> (use-modules (system foreign))
>>
>> (define %abort
>>   (dynamic-func "abort" (dynamic-link)))
>>
>> (let ((ptr (make-pointer 123 %abort)))
>>   (display "hello\n")
>>   (gc))
>>
>> Guile is free to collect ‘ptr’ when ‘gc’ is called since it has become
>> unreachable at that point; that’s what 2.2.0 does, as explained in
>> ‘NEWS’.
>>
>> However, there’s a finalizer here so collecting ‘ptr’ has an observable
>> side effect.  This side effect makes the semantic change visible: the
>> “expected” semantics would be that ‘ptr’ is not subject to GC while it’s
>> in scope.
>
> This would indicate that the user has erroneous expectations ;-)
>
> Note that here since (gc) is in tail position, ptr is in fact not
> protected in any way, even given this mental model, though with a single
> thread it may be that the collection actually happens later in 2.0 given
> that finalizers are run by asyncs.  Also ptr is not protected during the
> "display" either, in 2.0; in 2.0 this "let" reduces to "begin" under
> peval since the ptr is not used.

Indeed (in practice ‘ptr’ would happen to be finalized later, but that’s
“out of luck”.)

>> (In 2.0 the finalizer is not called until ‘ptr’ is no longer in scope.)
>>
>> I’m not sure this counts as a bug, but it’s certainly a pitfall when
>> working with finalizers and the FFI.
>>
>> Thoughts?
>
> For me, I don't think this is a bug.  Rather the contrary, as it's more
> in spirit with safe-for-space principle that a continuation should only
> keep alive those values that it uses; any other data should be available
> for the GC to reclaim.
>
> In any case, I think this manual section treats the problem adequately,
> for me at least:
>
>   https://www.gnu.org/software/guile/manual/html_node/Foreign-Object-Memory-Management.html
>
> Would you like to add something there?

Hmm, I don’t think so (great section, BTW).

I need to chew a bit more on this, but the conclusion is probably that
my expectations were incorrect, indeed.  :-)

Thanks,
Ludo’.