A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2005-May/053933.html below:

[Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanup

[Python-Dev] Combining the best of PEP 288 and PEP 325: generator exceptions and cleanupTim Peters tim.peters at gmail.com
Thu May 19 20:57:32 CEST 2005
[Phillip J. Eby]
> Now you've shaken my faith in Uncle Timmy.  :)

Now, now, a mere technical matter is no cause for soul-damning heresy!

>  Seriously, he did *say*:
> 
> """For example, it doesn't know the difference between an object
> that's in a trash cycle, and an object that's not in a trash cycle but
> is reachable only from trash cycles."""
>
> So now I wonder what he *did* mean.

What I said, of course ;-)  I hope my later email clarified it.  gc
knows which trash objects have __del__ methods, and which don't. 
That's all it needs to know so that a __del__ method on an object
that's not in a trash cycle but is reachable only from trash cycles
will get reclaimed (provided that no __del__ method on a predecessor
object that's not in a trash cycle but is reachable only from trash
cycles resurrects it).  gc doesn't know whether the set of objects it
_intends_ to call tp_clear on are or aren't in cycles, but all objects
directly in __del__ free cycles are included in that set.  That's
enough to ensure that trash "hanging off of them" sees its refcounts
fall to 0 as gc applies tp_clear to the objects in that set.  Note
that this set can mutate as gc goes along:  calling tp_clear on one
object can (also as a side effect of refcounts falling to 0) remove
any number of other objects from that set (that's why I said "intends"
above:  there's no guarantee that gc will end up calling tp_clear on
any object other than "the first" one in the set, where "the first" is
utterly arbitrary now).

If an object in a trash cycle has a __del__ method, this is why the
cycle won't be reclaimed:  all trash objects with __del__ methods, and
everything transitively reachable from them, are moved to the
"finalizers" list early on.  If that happens to include a trash cycle
C, then all of C ends up in the "finalizers" list, and no amount of
tp_clear'ing on the objects that remain can cause the refcount on any
object in C to fall to 0.  gc has no direct knowledge of cycles in
this case either.
More information about the Python-Dev mailing list

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