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

[Jan Kanis]

2009/3/29  <castironpi-ng at comcast.net>:
> ----- Original Message -----
> From: "Greg Ewing" <greg.ewing at canterbury.ac.nz>
> To: castironpi-ng at comcast.net
> Cc: Python-ideas 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-ng 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.