[Python-Dev] Re: [PythonLabs] Re: [Python-checkins]python/dist/src/Modules gcmodule.c,2.33.6.5,2.33.6.6

[Tim Peters]

[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.