poss solution: GC and __del__ cycles

[Ken MacLeod]

Just getting into Python 2 and being wonderfully happy with GC, I was
reading about the unreclaimable objects, "Objects that have __del__()
methods and create part of a reference cycle cause the entire
reference cycle to be uncollectable."

I did a search on Deja on the topic, which included several good links
to python-dev, and I read there as well.

The problem is that you can't tell, with objects that have explicit
destructors, whether or not cycles will be cleared by calling __del__,
and you can't (or shouldn't?) call __del__ more than once.

The possible solution depends on the module author knowing the reason
for having explicit destructors, and providing a special one that the
GC can use to destroy the cycles.

If an object has a method __delgc__, the garbage collector can call
that method to release one side of cyclic references.  Following this
call, the object is effectivly "dead", but a call to __del__ will also
still be made after the next sweep when it's found that all the cyclic
references are now broken.  (For backwards compatibility, __del__
should not assume __delgc__ has been called.)

This solution can be tested without any patches to Py.  A Python
function can cycle through gc.garbage, check each object for a
__delgc__, and call it.  The GC will then collect the object on the
next sweep.  (Assuming the GC doesn't actually mark them as
uncollectable and never checks again.)  If this solution works, the
final GC update should also never call __delgc__ more than once
because it would be a waste of cpu cycles.

I'll create some test cases, but I'm hoping that someone with much
better understanding of the issues can think about it.

  -- Ken