Fwd: [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c
Wupsie, this was meant for all of python-dev ;P
---------- Forwarded message ----------
From: Thomas Wouters
... that throws cycle-gc in a hissy fit;
If by "hissy fit" you mean "gcmodule properly moves generators to the list of objects with finalizers, thereby preventing catastrophes", right, that's an intended hissy fit ;-) Well, I meant 'the durned thing refuses to do what I want it to do', which is clear cycles. I guess the hissy fit was mine ;) Did the best I could above, short of explaining exactly how failing to
identify an object with a finalizer can lead to disaster.
Much appreciated. Short course: gc obviously needs to know which objects are and are not
trash. If a finalizer is associated with an object in cyclic trash, then trash objects are potentially visible _from_ the finalizer, and therefore can be resurrected by running the finalizer. gc must therefore identify all trash objects reachable from trash objects with finalizers, because running finalizers _may_ make all such objects "not trash" again. Getting any part of that wrong can lead to calling tp_clear on an object that a finalizer actually resurrects, leading to symptoms from "hey, all the attributes on my object suddenly vanished by magic, for no reason at all" to segfaults.
So does that make all cycles involving only objects with finalizers
impervious to cycle-gc? I guess it'd have to be that way. That also means I
can stop searching for leaks in the C code, as we'll never be able to fix
them all, anyway (although 'good code' could manually break many of the
cycles.) At least not while keeping the tp_del of generator objects, not to
mention avoiding finalizers on other builtin objects. (None seem to have
them at the moment, they all do their stuff in tp_dealloc, which I guess
doesn't allow objects to reincarnate themselves.)
I'll see about fixing the Python code to avoid or explicitly break the
cycles. Maybe we can patch regrtest.py to take into account uncollectable
cycles, so that it could report them separately from refleaks. I'm going to
think about all this first, though.
Hrrm-hrrm'ly y'rs,
--
Thomas Wouters
On 3/29/06, Thomas Wouters
So does that make all cycles involving only objects with finalizers impervious to cycle-gc? I guess it'd have to be that way.
Er, I meant to say 'does that make all cycles involving just one object with
a finalizer impervious to cycle-gc'.
--
Thomas Wouters
[Thomas Wouters]
So does that make all cycles involving only objects with finalizers impervious to cycle-gc? I guess it'd have to be that way.
[again]
Er, I meant to say 'does that make all cycles involving just one object with a finalizer impervious to cycle-gc'.
Both are true, and both are implied by this sharper variant: all cycles containing at least one object with a finalizer [etc]
[Thomas Wouters] ...
not to mention avoiding finalizers on other builtin objects. (None seem to have them at the moment, they all do their stuff in tp_dealloc,
Right, generators are the only exception now (and there were no exceptions before 2.5).
which I guess doesn't allow objects to reincarnate themselves.)
This is the actual rule: tp_dealloc must not do anything that could confuse cyclic gc <0.5 wink>. I'm afraid that's the best writeup there is. If you have a few spare weeks, try to figure out exactly why subtype_dealloc() does what it does ;-)
... I'll see about fixing the Python code to avoid or explicitly break the cycles.
Or giving gc more smarts about generators specifically (see Phillip's msg).
Maybe we can patch regrtest.py to take into account uncollectable cycles, so that it could report them separately from refleaks. I'm going to think about all this first, though.
Hrrm-hrrm'ly y'rs, -- Hi! I'm a finalizer virus! copy me into your tp_del slot to help me spread!
LOL! Nice variation.
participants (2)
-
Thomas Wouters -
Tim Peters