Movatterモバイル変換
[0]ホーム
[Python-Dev] __traceback__ and reference cycles
Tim Peterstim.peters at gmail.com
Tue Aug 9 04:37:56 CEST 2005
[Tim Peters]>> If P3K retains them [__del__]-- or maybe even before --we should>> consider taking "the Java dodge" on this one. That is, decree that>> henceforth a __del__ method will get invoked by magic at most>> once on any given object O, no matter how often O is resurrected.[Phillip J. Eby]> How does that help?You have to dig into Armin's example (or read his explanation): everytime __del__ is called on one of his X objects, it creates a cycle bybinding sys.exec_info()[2] to the local vrbl `e_tb`. `self` isreachable from that cycle, so self's refcount does not fall to 0 when__del__ returns. The object is resurrected. When cyclic gc nextruns, it determines that the cycle is trash, and runs arounddecref'ing the objects in the cycle. That eventually makes therefcount on the X object fall to 0 again too, but then its __del__method also runs again, and creates an isomorphic cycle, resurrecting`self` again. Etc.Armin didn't point this out explicitly, but it's important to realizethat gc.garbage remains empty the entire time you let his program run. The object with the __del__ method isn't _in_ a cycle here, it'shanging _off_ a cycle, which __del__ keeps recreating. Cyclic gcisn't inhibited by a __del__ on an object hanging off a trash cycle(but not in a trash cycle itself), but in this case it's ineffectiveanyway.If __del__ were invoked only the first time cyclic gc ran, theoriginal cycle would go away during the next cyclic gc run, and a newcycle would not take its place.> Doesn't it mean that we'll have to have some way of keeping track of> which items' __del__ methods were called?Yes, by hook or by crook; and yup too, that may be unattractive.
More information about the Python-Devmailing list
[8]ページ先頭