<br>Wupsie, this was meant for all of python-dev ;P<br><br>---------- Forwarded message ----------<br><span class="gmail_quote">From: <b class="gmail_sendername">Thomas Wouters</b> <<a href="mailto:thomas@python.org">thomas@python.org
</a>><br>Date: Mar 29, 2006 1:34 AM<br>Subject: Re: [Python-Dev] [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c<br>To: Tim Peters <<a href="mailto:tim.peters@gmail.com">tim.peters@gmail.com</a>>
<br><br></span><div style="direction: ltr;"><br><div><span class="gmail_quote">On 3/29/06, <b class="gmail_sendername">Tim Peters</b> <<a href="mailto:tim.peters@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
tim.peters@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
... that throws cycle-gc in a hissy fit;<br></blockquote></div><div style="direction: ltr;"><span class="q"><br>If by "hissy fit" you mean "gcmodule properly moves generators to the<br>list of objects with finalizers, thereby preventing catastrophes",
<br>right, that's an intended hissy fit ;-)
</span></div><div style="direction: ltr;"><div><br>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 ;)<br><br></div></div><div style="direction: ltr;">
<span class="q"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Did the best I could above, short of explaining exactly how failing to<br>identify an object with a finalizer can lead to disaster.</blockquote></span></div><div style="direction: ltr;"><div><br>Much appreciated.<br></div>
</div><div style="direction: ltr;"><span class="q"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Short course: gc obviously needs to know which objects are and are not<br>trash. If a finalizer is associated with an object in cyclic trash,<br>then trash objects are potentially visible _from_ the finalizer, and<br>therefore can be resurrected by running the finalizer. gc must
<br>therefore identify all trash objects reachable from trash objects with<br>finalizers, because running finalizers _may_ make all such objects<br>"not trash" again. Getting any part of that wrong can lead to calling
<br>tp_clear on an object that a finalizer actually resurrects, leading to<br>symptoms from "hey, all the attributes on my object suddenly vanished<br>by magic, for no reason at all" to segfaults.<br></blockquote>
</span></div><div style="direction: ltr;">
</div><br>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.)
<br><br>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.
<br><br><span id="st" name="st" class="st">Hrrm</span>-<span id="st" name="st" class="st">hrrm</span>'ly y'rs,<br></div><div style="direction: ltr;"><span class="sg">-- <br>Thomas Wouters <<a href="mailto:thomas@python.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
thomas@python.org</a>><br><br>Hi! I'm a finalizer virus! copy me into your tp_del slot to help me spread!</span></div>