Guardians....

[Marius Vollmer]

Hi,

I am afraid I have to come back to guardians once more.

I stumpled over our peculiar guardians while trying to improve the
weak hash table marking algorithm so that it will properly deal with
references from the non-weak part to the weak part.  (For example,
referencing a weak key from a non-weak value should not prevent that
entry to be dropped once there are no other references to the key or
value.)

There are some significant differences between our guardian semantics
and the ones described in the Guardian paper.  (Not "The Guardian",
this one:
ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/guardians.ps.gz)

I think we should go back to the original guardian semantics since
they are everything you need, much simpler, and better known.

The differences, afaik, are these:

 - With our guardians and by default, you can only put a single object
   into a single guardian.  With the orginal guardians, you can put a
   single object into as many guardians as many times as you want and
   you would get it back from each guardian that many times.

   We have the option of 'sharing' guardians that will accept an
   object that is already guarded (but they are not the default).
   When an object is in a default 'greedy' guardian and a sharing one,
   it will be returned from the greedy one first.

 - Our guardians make guarantees about the order in which objects are
   returned from them, while the original guardians do not.  Our
   guardians only return objects from a guardian that are not
   referenced by other objects that are still in a guardian.  As a
   consequence, cycles can not be handled.  They will be dropped from
   a guardian and not returned at all.  An object will be dropped as
   soon as it is part of any cycle, not just a cycle formed only by
   guarded objects.

I have the impression that these differences are mostly motivated by
seeing guardians as being only good for finalization (as in C++
destructors).  You normally want to finalize objects in a certain
order, and it makes only sense to finalize them once.

I think guardians should not try to solve these problems of
finalization and lose their original generality for that.

If a program puts an object into more than one guardian, we should
assume that there is a good reason for that.  Maybe one guardian is
for finalizing and the other is for updating some statistics.
Therefore, and to be compatible with the original semantics by
default, guardians should not be made greedy by default.

Of course, failing to return objects with cyclic dependencies from a
guardian is very suboptimal even more so since we already fail on any
cycles even if only one object of that cycle is guarded.

In fact, I don't see a reason to provide greedy guardians at all.  Why
should you care whether someone else is also interested in learning
about the death of some object?  In my view, it should really be a
rare occassion when putting an object into two guardians is an error.

When you want to make sure that object FOO is returned from a guardian
before object BAR is, you can put BAR into a global data structure to
keep it alive.  When FOO has died, you can remove BAR from that
structure and let it die as well.  This explicit approach allows much
more control over the order of actions than letting the guardians do
it implicitly by following _all_ references.  Unwanted cycles can be
avoided easily, for example.


I therefore propose to go back to the simple guardian semantics as
described in the paper by Dybvig et al.  That would be an incompatible
change, and so I will try to find people who are relying on the
current semantics.

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