The order of objects returned from a guardian

The order of objects returned from a guardian

[Marius Vollmer]

Hi,

Guile's guardians currently make the guarantee that "it is impossible
for a guardian to return a 'contained' object before its 'containing'
object."

I am considering removing this guarantee since it makes it impossible
for guardians to deal with cycles among guarded objects, and because
it is not part of the semantics of guardians as proposed in the paper
by Dybvig et al[1].

So, do you rely on this ordering guarantee?

If you do, you would need to take care of the ordering yourself, which
is quite easy by keeping objects alive in a global data structure
until they are no longer needed.

[1] ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/guardians.ps.gz
-- 
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

64bit guile: one bug found, one improvement suggested

[Roland Orre]

The (small) bug may be corrected in later version (I'm still
using the old style (early 1.7) uniform arrays). The improvement
suggested below is actually part of a general 32/64 bit problem.

bug:
size of scm_tc7_ivect and scm_tc7_uvect is long, but should be int.
causes: on 64 bit machine, there are no 32 bit int vectors available.
(I've fixed this locally)

improvement suggestion:
size of SCM should be configurable to 32 bit on 64 bit machine.
As it is now, it causes a lot of wasted memory and I guess also
unnecessary usage of memory band width.

This is a somewhat bigger change as most addressing needs to be
base relative. I guess there are utilites available to allocate
memory within certain (e.g. 32 bit) boundaries, (there was in VMS
I used once) but haven't found any in GNU/Linux, apart from
possibly start in mmap.
Maybe even gcc provides a nice solution to this, but haven't
found anything (someth like: short pointer and long pointer
which I think I've seen in some languages long time ago).

/Roland Orre




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

Re: The order of objects returned from a guardian

[Neil Jerram]

Marius Vollmer wrote:
> 
> So, do you rely on this ordering guarantee?

No, my uses of guardians don't rely on this.

Also I'm pretty sure that I'd expect any object added to a guardian to
be returned when that object becomes inaccessible.  If cycles can make
this untrue, even when the whole cycle is inaccessible, that's pretty bad.

So I'm happy with your proposal.

> If you do, you would need to take care of the ordering yourself, which
> is quite easy by keeping objects alive in a global data structure
> until they are no longer needed.

Not sure what you mean by this, though.  How would this generate an
ordering?

	Neil


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

Re: The order of objects returned from a guardian

[Marius Vollmer]

Neil Jerram <neil@ossau.uklinux.net> writes:

>> If you do, you would need to take care of the ordering yourself, which
>> is quite easy by keeping objects alive in a global data structure
>> until they are no longer needed.
>
> Not sure what you mean by this, though.  How would this generate an
> ordering?

Say you need BAR during the finalization of FOO.  In order to ensure
that BAR is not itself finalized before FOO is, you can keep BAR
accessible by putting it into a global data structure.  As long as BAR
is accessible, it will not be returend by a guardian.  When you have
finalized FOO, you can remove BAR from that data structure.

(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.)

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


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

Re: The order of objects returned from a guardian

[Marius Vollmer]

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