[Python-Dev] PEP 442: Safe object finalization
eliben at gmail.com
Sat May 18 15:56:26 CEST 2013
On Sat, May 18, 2013 at 6:47 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sat, 18 May 2013 06:37:54 -0700
> Eli Bendersky <eliben at gmail.com> wrote:
> > Great PEP, I would really like to see this happen as it defines much
> > semantics for finalization than what we currently have. One small
> > 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
> > 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
> > 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?
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 ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev