[Python-ideas] python-like garbage collector & workaround

[Aaron Brady]

On Mar 30, 7:36 pm, Jan Kanis <jan.ka... at phil.uu.nl> wrote:
> 2009/3/29  <castironpi... at comcast.net>:
>
> > ----- Original Message -----
> > From: "Greg Ewing" <greg.ew... at canterbury.ac.nz>
> > To: castironpi... at comcast.net
> > Cc: Python-id... at python.org
> > Sent: Saturday, March 28, 2009 5:32:27 PM GMT -06:00 US/Canada Central
> > Subject: Re: [Python-ideas] python-like garbage collector & workaround
>
> > castironpi... at comcast.net wrote:
>
> >  > I'm considering a workaround that performs GC in two steps.  First, it
> >> requests the objects to drop their references that participate in the
> >> cycle.  Then, it enqueues the decref'ed object for an unnested
> >> destruction.
>
> Castironpi,
> I don't think your solution solves the problem. In a single stage
> finalization design, it is allways possible to call the destructors of
> the objects in the cycle in random order. The problem is that now when
> A gets finalized, it cannot use its reference to B anymore because B
> may have already been finalized, and thus we cannot assume B can still
> be used for anything usefull. The problem, of course, is that one of A
> or B may still need the other during its finalization.
>
> In your solution, the real question is what the state of an object is
> supposed to be when it is in between the two stages of finalization.
> Is it still supposed to be a fully functional object, that handles all
> operations just as if it were still fully alive? In that case the
> object can only drop the references that it doesn't actually need to
> perform any of its operations (not just finalization). But if we
> assume that an object has all its references for a reason, there is
> nothing it can drop. (except if it uses a reference for caching or
> similar things. But I think that is only a minority of all use cases.)
> If you propose an object counts as 'finalized' (or at least, no longer
> fully functional) when it is in between stages of finalization, we
> have the same problem as in the single stage random order
> finalization: other objects that refer to it can no longer use it for
> anything usefull.
>
> The only option that is left is to have the object be in some
> in-between state. But that really complicates Pythons object model,
> because every object now has two visible states: alive and
> about-to-die. So every object that wants to support this form of
> finalization has to specify what kind of operations are still
> available in its about-to-die state, and all destructors of all
> objects need to restrict themselves to only these kind of operations.
> And then, of course, there is still the question of what to do if
> there are still cycles left after the first stage.
>
> If you still think your proposal is usefull, you'll probably need to
> explain why these problems don't matter enough or whether there are
> important use cases that it solves.
> _______________________________________________
> Python-ideas mailing list
> Python-id... at python.orghttp://mail.python.org/mailman/listinfo/python-ideas

Hi, sorry for the delay.  Not to beat a dead horse, but I've tried c-
l-
py for the technical discussion.

For user-defined types, the only option is currently to scan the
'gc.garbage' collection.  I want to provide more options for the users
of my system.

I was thinking about implementing weak-refs, so long as it's worth
it.  That's one approach that I understand doesn't have the same
problem.  However, that risks losing an object in the middle of
execution, not just when both have left reachability.

Another option is to add a 'is reachable' system call.  Weak-refs
would be akin to an 'still exists' call.

class StarCrossedLover:
   def __init__( self, other ):
       self.other= other
   def __del__( self ):
       kill( self.other )

romero= StarCrossedLover( )
joriet= StarCrossedLover( )

In this example, I think weak-refs would be most accurate.  However,
that litters the entire class code with weak-ref testing.  Under my
model, self.other may or may not be valid in the destructor.  With
weak-refs, self.other may or may not be valid anywhere at all!
However, they are consistent and __del__ methods can always get
called.  Should I add them?

Thanks in advance.