[Jeremy Hylton] > We've got the first version of boom nailed, but we've got the same > problem in handle_finalizers(). The version of boom below doesn't blow > up until the second time the has_finalizer() is called. > > I don't understand the logic in handle_finalizers(), though. If the > objects are all in the finalizers list, why do we call has_finalizer() a > second time? Shouldn't everything has a finalizer at that point? Nope -- the parenthetical /* Handle uncollectable garbage (cycles with finalizers). */ comment is incomplete. The earlier call to move_finalizer_reachable() also put everything reachable only *from* trash cycles with finalizers into the list. So, e.g., if the trash graph is like A<->B->C and A has a finalizer but B and C don't, they're all in the finalizers list (at this point) regardless. But B and C aren't stopping the blob from getting collected, and we're trying to do the user a favor by putting only A (the troublemaker) into gc.garbage. It's an approximation, though. For example, if A and C both had finalizers, A and C would both be put into gc.garbage, despite that C's finalizer isn't stopping anything from getting collected. The comments are apparently a bit out of synch with the code, because 17 months ago all instance objects in the finalizers list were put into gc.garbage (regardless of whether they had __del__). The checkin comment for rev 2.28 sez the __del__ change was needed to fix a bug; but I'm too groggy to dig more now.
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