Tim Peters <t...@python.org> added the comment:
> I'm often amazed it works at all, let alone perfectly. ;-P Indeed! Every time I take a break from gc and come back, I burn another hour wondering why it doesn't recycle _everything_ ;-) > But what happens if the GC doesn't see that WZ is trash? > Then it will not be cleared. Hang it off Y so the GC > can't find it. In that case it won't think C is trash either (a weakref holds a strong reference to its callback), so C won't be tp_clear'ed - if WZ isn't in the unreachable set, C can't be either. > We can set things up so that Z is freed before WZ (e.g. > WZ in a second and newer cycle). Then, the callback > might still run. Since C hasn't been damaged, and nothing reachable from C would have been considered trash either, I don't see a problem. > On further thought, this seems safe (but maybe broken) because > of the handle_weakrefs() logic. The GC will think WZ is going > to outlive Z so it will call it before doing any tp_clear calls. Don't think that applies. As above, WZ isn't in the unreachable set, so gc knows nothing about it. Z will eventually be reclaimed via refcounting side effect, C _will_ run, and then WZ, and then C, will be reclaimed by refcounting. Or am I missing something? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38006> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
