On Sat, May 18, 2013 at 6:47 AM, Antoine Pitrou <solip...@pitrou.net> wrote:
> On Sat, 18 May 2013 06:37:54 -0700 > Eli Bendersky <eli...@gmail.com> wrote: > > Great PEP, I would really like to see this happen as it defines much > saner > > semantics for finalization than what we currently have. One small > question > > below: > > > > > > This PEP proposes to turn CI disposal into the following sequence (new > > > steps are in bold): > > > > > > 1. Weakrefs to CI objects are cleared, and their callbacks called. At > > > this point, the objects are still safe to use. > > > > > > 2. **The finalizers of all CI objects are called.** > > > > > > 3. **The CI is traversed again to determine if it is still isolated. > > > If it is determined that at least one object in CI is now reachable > > > from outside the CI, this collection is aborted and the whole CI > > > is resurrected. Otherwise, proceed.** > > > > > > > Not sure if my question is the same as Armin's here, but worth a try: by > > saying "the CI is traversed again" do you mean the original objects from > > the CI as discovered earlier, or is a new scan being done? What about a > new > > object entering the CI during step (2)? I.e. the original CI was A->B->A > > but now one of the finalizers created some C such that B->C and C->A > adding > > it to the connected component? > > It is the original CI which is traversed. If a new reference is > introduced into the reference chain, the traversal in step 3 will > decide to resurrect the CI. This is not necessarily a problem, since > the next GC collection will try collecting again. > > > Reading your description in (3) strictly it says: in this case the > > collection is aborted. This CI will be disposed next time collection is > > run. Is this correct? > > Yup. > Thanks, this actually makes a lot of sense. It's strictly better than the current situation where objects with __del__ are never collected. In the proposed scheme, the weird ones will be delayed and some really weird ones may never be collected, but the vast majority of __del__ methods do no resurrection so usually it will just work. This is a great proposal - killer new feature for 3.4 ;-) Eli
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com