[Python-Dev] Fwd: [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c

[Thomas Wouters]

Wupsie, this was meant for all of python-dev ;P

---------- Forwarded message ----------
From: Thomas Wouters <thomas at 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 at gmail.com>


On 3/29/06, Tim Peters <tim.peters at 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 at python.org>

Hi! I'm a finalizer virus! copy me into your tp_del slot to help me spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060329/e1fc1748/attachment.html