Lines Matching refs:cyclic

5 for that matter) during cyclic gc:
40 The primary thing it missed is that when a weakref to a piece of cyclic
43 possibly resurrect an insane object (one for which cyclic gc has called-- or
59     Clearing cyclic trash can call Python code.  If there are weakrefs to
60     any of the cyclic trash, then those weakrefs can be used to resurrect
61     the objects.  Therefore, *before* clearing cyclic trash, we need to
77 Before 2.3.3, Python's cyclic gc didn't pay any attention to weakrefs.
87 becomes part of a clump of cyclic trash.  When enough cycles are broken by
88 cyclic gc that the object is reclaimed, the callback is invoked.  If it's
105 the current collection, and nothing reachable from it would be in cyclic
111 More, if the callback itself is in cyclic trash, then the weakref to which
114 not have been cyclic trash.
117 weakly referenced object, all be in cyclic trash at the same time.  This
127 callbacks in cyclic trash.  Since the weakrefs *are* trash, and there's no
129 cyclic trash, it's defensible to first clear weakrefs with callbacks.  It's
146 latter weakrefs may or may not be part of cyclic trash.
149 on all the objects in cyclic trash,
168 Then we can call tp_clear on all the cyclic objects and never trigger
174 (if any) *on* the callback objects that were also part of cyclic trash won't
176 start.  Callbacks on the callback objects that were not part of cyclic trash
178 reachable from them was part of cyclic trash, so gc didn't do any damage to
196     that does use cyclic data structures.  You reason about the design,