Andy Wingo <wi...@pobox.com> skribis: > l...@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’.
