Lines Matching full:that
5 for that matter) during cyclic gc:
10 If that can happen, then the Python code can resurrect unreachable objects
11 too, and gc can't detect that without starting over. Since gc eventually
21 OTOH, it's OK to run Python-level code that can't access unreachable
22 objects, and sometimes that's necessary. The chief example is the callback
26 so it's also safe to invoke the callback (although that's trickier than it
40 The primary thing it missed is that when a weakref to a piece of cyclic
42 materializing a strong reference to that weakref's CT referent, and so
44 will call before it's done --tp_clear()). It's not even necessarily that a
47 too, and they can do ordinary things with weakrefs that end up resurrecting
53 focussed test cases attached to that bug report are now part of Python's
66 Alas, doing just that much doesn't work, because it overlooks what turned
67 out to be the much subtler problems that were fixed earlier, and described
69 all callbacks encountered can be run later. That's explained in horrid
81 that a given object has died, via a callback function. The weakly
83 is that the weakly referenced object is unreachable trash at the time the
86 That's usually true, but not always. Suppose a weakly referenced object
88 cyclic gc that the object is reclaimed, the callback is invoked. If it's
92 that have already suffered a tp_clear() call. There's no guarantee that an
98 [That missed that, in addition, a weakref to CT can exist outside CT, and
102 Note that if it's possible for the callback to get at objects in the trash
103 cycles, it must also be the case that the callback itself is part of the
108 [Except that a non-CT callback can also use a non-CT weakref to get at
116 So a problem here requires that a weakref, that weakref's callback, and the
121 modules had been torn down. That creates many trash cycles (esp. those
124 tests that segfault before shutdown.
130 a feature of Python's weakrefs too that when a weakref goes away, the
140 Just that much is almost enough to prevent problems, by throwing away
141 *almost* all the weakref callbacks that could get triggered by gc. The
142 problem remaining is that clearing a weakref with a callback decrefs the
151 [That was always wrong: we can't stop Python code from running when gc
154 matter of course, drop the refcount on that object to 0, and its __del__
156 code that could access CT.]
159 grew a new private function (_PyWeakref_ClearRef) that does only part of
162 _PyWeakref_ClearRef(wr) ensures that wr's callback object will never
171 [As above, not so: it means never trigger Python code that can access CT.]
173 After we do that, the callback objects still need to be decref'ed. Callbacks
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
181 [That's so. In addition, now we also invoke (if any) the callbacks on
182 non-CT weakrefs to CT objects, during the same pass that decrefs the
187 instead. That would have been much easier. Jim Fulton gave a strong
188 argument against that (on Python-Dev):
195 Now, suppose you have a design that makes has no __del__ methods but
196 that does use cyclic data structures. You reason about the design,
209 that's not good (a primary reason not to collect cycles with objects with
