Guido van Rossum wrote:
>
> Let me explain something about the new GC code. It does *not* hide
> missed DECREFs. If you miss a DECREF, the GC code thinks there's a
> global pointer to the object that keeps it alive, and will not release
> the object.
>
Sure.
> I don't know what Barry found, but I suspect they are genuine cycles
> created during the exception initialization. It's easy enough to
> create cycles, e.g. form module -> class -> function -> module, or
> module -> function -> module, when defining classes or functions.
>
> The new GC code is *intended* to clean up exactly such cycles!
My point is that it is better not to rely on the GC code for the core
if we're not crystal clear when and why cycles are created. And even if
we spot them all (and mark these locations in the source), it is always
better to try breaking the cycles explicitely.
It's a fact that we're not crystal clear where all these cycles are
created (be they genuine, easily introduced or not). This is not a good
thing and I don't want to support the idea of tolerating this situation.
I wish I had Purify to help Barry cleaning this up...
--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4