GNU bug report logs -
#10668
FFI: ‘set-pointer-finalizer!’ overrides the previous finalizer
Previous Next
Reported by: ludo <at> gnu.org (Ludovic Courtès)
Date: Mon, 30 Jan 2012 22:33:01 UTC
Severity: normal
Done: Andy Wingo <wingo <at> pobox.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10668 in the body.
You can then email your comments to 10668 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guile <at> gnu.org
:
bug#10668
; Package
guile
.
(Mon, 30 Jan 2012 22:33:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
ludo <at> gnu.org (Ludovic Courtès)
:
New bug report received and forwarded. Copy sent to
bug-guile <at> gnu.org
.
(Mon, 30 Jan 2012 22:33:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
The ‘set-pointer-finalizer!’ procedure is harmful because it erases any
previously set finalizer.
Said finalizer could come from a guardian:
(define ptr (make-pointer 123))
(define g (make-guardian))
(g ptr)
(set-pointer-finalizer! ptr (dynamic-func "scm_is_pair" (dynamic-link)))
(set! ptr #f)
(gc)
(g) ;; Should return PTR.
=> #f
or from a weak hash table:
(define ptr (make-pointer 123))
(define t (make-weak-value-hash-table))
(hashq-set! t ptr #t)
(set-pointer-finalizer! ptr (dynamic-func "scm_is_pair" (dynamic-link)))
(set! ptr #f)
(gc)
(gc)
(hash-fold alist-cons '() t)
=> ((#<pointer 0x7b> . #t)) ;; Should be the empty list.
There are several ways to fix this:
1. Deprecate ‘set-pointer-finalizer!’ in favor of guardians, with the
problem that it would be up to the user to actually call the
guardians.
2. Implement ‘set-pointer-finalizer!’ in terms of guardians, with a
gc-hook to automatically call the guardians and invoke any
finalizers.
3. Fix ‘set-pointer-finalizer!’ to honor the previously-set finalizer,
if any. This means (a) finding a way to keep previous-finalizer
info around, and (b) duplicating part of the (hairy) code from
guardians.c to honor the previous finalizer.
None of these solutions is really pleasant.
Thoughts?
Thanks,
Ludo’.
Reply sent
to
Andy Wingo <wingo <at> pobox.com>
:
You have taken responsibility.
(Fri, 06 Jul 2012 18:32:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
ludo <at> gnu.org (Ludovic Courtès)
:
bug acknowledged by developer.
(Fri, 06 Jul 2012 18:32:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 10668-done <at> debbugs.gnu.org (full text, mbox):
On Mon 30 Jan 2012 23:31, ludo <at> gnu.org (Ludovic Courtès) writes:
> The ‘set-pointer-finalizer!’ procedure is harmful because it erases any
> previously set finalizer.
>
> Said finalizer could come from a guardian:
>
> (define ptr (make-pointer 123))
> (define g (make-guardian))
> (g ptr)
> (set-pointer-finalizer! ptr (dynamic-func "scm_is_pair" (dynamic-link)))
> (set! ptr #f)
> (gc)
>
> (g) ;; Should return PTR.
> => #f
This has worked since 75ba64d6797f5857cc9885eb753126119a8c8b68.
Andy
--
http://wingolog.org/
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 04 Aug 2012 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 327 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.