CPython's cyclic garbage collector (was [Python-ideas] Automatic context managers)

[Ian Kelly]

On Fri, Apr 26, 2013 at 1:31 PM, Dave Angel <davea at davea.name> wrote:
> On 04/26/2013 01:57 PM, Chris Angelico wrote:
>> And yeah. If you catch the exception inside __del__, you can cope with
>> the destructed object yourself (or LBLY, if you wish). Alternatively,
>> you just proceed as normal, and when your __del__ throws an exception,
>> the gc then copes (not sure *how* it should cope - log it to stderr
>> and carry on?). Same as normal exception handling.
>>
>> The advantage of this style is that the code to deal with the cycle is
>> kept right in the cyclic object's destructor - right where the problem
>> is. Doing it through gc.garbage requires that some other operation
>> periodically check for garbage - after the GC has done its own
>> periodic check. Seems simpler/cleaner to do it as part of the gc run
>> itself.
>>
>
> You must think me dense by now.  But I don't understand what the two
> different garbage collection operations are that you're positing.
>
> As far as I know, there's ref counting, which is quick, and frees something
> as soon as the count goes to zero.  Then there's gc, which has to scan
> through all the objects from a known starting set, and identify those things
> which aren't accessible, and free any that don't have a __del__() method.
>
> And it's only in the gc step that cycles and such are identifiable.

Whenever the GC finds a cycle that is unreferenced but uncollectable,
it stores those objects in the list gc.garbage.  At that point, if the
user wishes to clean up those cycles, it is up to them to delve into
gc.garbage, untangle the objects contained within, break the cycles,
and remove them from the list so that they can be freed by the ref
counter.  This user-supplied step is what Chris is referring to as
"some other" periodic check.  If the user does not do this, then those
objects simply remain in the gc.garbage list until the program
terminates.