Re: The order of objects returned from a guardian

[Marius Vollmer <mvo@zagadka.de>]

Marius Vollmer <mvo@zagadka.de> writes:

> (I am a bit worried right now that the 'obvious' approach of putting
> FOO and BAR into a weak key hashtable with FOO as the key and BAR as
> the value does conflict a bit with my original goal of breaking up
> cycles from strong values to weak keys.  With the code that I have
> now, both FOO and BAR are not considered accessible just by virtue of
> being in the hashtable.  Thus, once FOO is considered inaccessible,
> BAR might be inaccessible as well; both could be returned from
> guardians in any order.  Hmm.)

I have now thought a bit more about this, and am no longer worried.
This is now the reference documentation of make-guardian:

 -- Scheme Procedure: make-guardian
 -- C Function: scm_make_guardian ()
     Create a new guardian.  A guardian protects a set of objects from
     garbage collection, allowing a program to apply cleanup or other
     actions.

     `make-guardian' returns a procedure representing the guardian.
     Calling the guardian procedure with an argument adds the argument
     to the guardian's set of protected objects.  Calling the guardian
     procedure without an argument returns one of the protected objects
     which are ready for garbage collection, or `#f' if no such object
     is available.  Objects which are returned in this way are removed
     from the guardian.

     You can put a single object into a guardian more than once and you
     can put a single object into more than one guardian.  The object
     will then be returned multiple times by the guardian procedures.

     A object is eligible to be returned from a guardian when it is no
     longer referenced from outside any guardian.

     There is no guarantee about the order in which objects are returned
     from a guardian.  If you want to impose an order on finalization
     actions, for example, you can do that by keeping objects alive in
     some global data structure until they are no longer needed for
     finalizing other objects.

     Being an element in a weak vector, a key in a hash table with weak
     keys, or a value in a hash table with weak value does not prevent
     an object from being returned by a guardian.  But as long as an
     object can be returned from a guardian will it not be removed from
     such a weak vector or hash table.  In other words, a weak link
     does not prevent an object from being considered collectable, but
     being inside a guardian prevents a weak link from being broken.

     A key in a weak key hash table can be though of as having a strong
     reference to its associated value as long as the key is accessible.
     Consequently, when the key only accessible from within a guardian,
     the reference from the key to the value is also considered to be
     coming from within a guardian.  Thus, if there is no other
     reference to the value, it is eligible to be returned from a
     guardian.


-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user