GNU bug report logs - #10668
FFI: ‘set-pointer-finalizer!’ overrides the previous finalizer

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: ludo <at> gnu.org (Ludovic Courtès)
Subject: bug#10668: closed (Re: bug#10668: FFI: ‘set-pointer-finalizer!’
 overrides the previous finalizer)
Date: Fri, 06 Jul 2012 18:32:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#10668: FFI: ‘set-pointer-finalizer!’ overrides the previous finalizer

which was filed against the guile package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 10668 <at> debbugs.gnu.org.

-- 
10668: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10668
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Andy Wingo <wingo <at> pobox.com>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 10668-done <at> debbugs.gnu.org
Subject: Re: bug#10668: FFI: ‘set-pointer-finalizer!’ overrides the previous finalizer
Date: Fri, 06 Jul 2012 20:26:20 +0200

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/

[Message part 3 (message/rfc822, inline)]

From: ludo <at> gnu.org (Ludovic Courtès)
To: bug-guile <at> gnu.org
Subject: FFI: ‘set-pointer-finalizer!’ overrides
	the previous finalizer
Date: Mon, 30 Jan 2012 23:31:59 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.