Wupsie, this was meant for all of python-dev ;P ---------- Forwarded message ---------- From: Thomas Wouters <thomas@python.org> Date: Mar 29, 2006 1:34 AM Subject: Re: [Python-Dev] [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c To: Tim Peters <tim.peters@gmail.com> On 3/29/06, Tim Peters <tim.peters@gmail.com> wrote:

... 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 <thomas@python.org> Hi! I'm a finalizer virus! copy me into your tp_del slot to help me spread!