Re: 1.6.0 and guardians

[Dirk Herrmann]

On 6 Sep 2001, Michael Livshin wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > On 6 Sep 2001, Michael Livshin wrote:
> > 
> > > the situation is actually very similar to the situation with file
> > > ports.  an open file port holds a scarce system resource (a file
> > > descriptor).  a live greedy guardian also holds a scarce system
> > > resource -- the ability to guard the objects in it.
> > > 
> > > ports have the `close' function, in order to achieve explicit control
> > > over the use of their scarce resource.  so do greedy guardians.
> > 
> > Hmmm... I still don't get it:  What is the resource you want to re-use by
> > destroying the guardian?
> 
> the ability to greedily guard the objects in it.

I am trying to get this right:  You want to gain back the ability to guard
the objects in the guardian, right?

As you say, the solution to simply let the guardian get garbage-collected
is not sufficient, since you don't know when the guardian gets collected,
and at which time the individual object will be available for re-guarding.

One option is to destroy the guardian.  This gives you immediately back
the possibility to guard all the objects in it.  However, it does not
offer you the potential to _selectively_ unguard certain objects.  You
unguard all of them.  I understand that you have a special situation
in mind:  Dropping all references to a guardian, and immediately wanting  
back the possibility to re-guard the corresponding objects with some other
guardian.

I don't see the need for such a functionality, but given there is some
sense in it (in interactive development), the possibility to provide
'guarded?' and 'unguard' functions seems to be a better solution, since it
allows to achieve the same goals on an per-object base.  Further, it
does not lead to 'destroyed' guardian objects hanging around.

> neither do I.  but if you ever want to make a non-permanent greedy
> guardian (whether it's useful or not is irrelevant as long as it's
> _possible_), then you need a way to ensure, prior to getting rid of
> it, that the scarce system resource it holds gets freed.

Hmmm.  As long as some 'guarded?' predicate is true for some object, the
assumed 'unguard' function could access the corresponding guardian (since
'guarded?' is answered based on the same doubly weak hashing table in
which the guardian of each guarded object is stored).  That is, even if
you lost all references to a guardian, you still could do 'unguard' on the
objects contained in it.

BTW:  There is one point about guardians that is absolutely important, but
does not seem to be reflected in the current code (or at least I could not
find it):  Between the mark and sweep phases, the guardian's
zombify_and_mark function has to be executed _before_ the weak objects are
scanned.

Best regards
Dirk Herrmann