[Python-checkins] peps: New PEP: Safe object finalization

[Terry Reedy]

On 5/17/2013 5:20 PM, antoine.pitrou wrote:
> http://hg.python.org/peps/rev/0763444c74b3
> changeset:   4890:0763444c74b3
> user:        Antoine Pitrou <solipsis at pitrou.net>
> date:        Fri May 17 23:17:31 2013 +0200
> summary:
>    New PEP: Safe object finalization
My summary:

A . __del__ method can do anything that any method can do. This includes 
'insane' things (for a deletion process) like constructing new links. 
This imposes constraints and a cost on the 'ghost cycle' deletion 
process. A ghost cycle is dead but still 'here' in the sense of taking 
up space and gc time. The current solution is to not call finalizers in 
ghost cycles.

Key idea: shift the cost (in the form of keeping some ghost cycles 
around forever, and making efforts to avoid creating immortal ghosts) 
from everyone to those who write 'insane' finalizers for objects that 
might end up in ghost cycles.

The gain for most is that ghost cycles, even those with sane finalizers, 
get sent to the great beyond, freeing space and time in the world we 
care about. The cost for the few is possible indeterminate behavior. 
Whether a ghost cycle is deleted or resurrected, and in the latter case, 
which reference causes the resurrection, may depend on the arbitrary 
order of calling finalizers.

I think it a good tradeoff. +1

Key insight (which seems correct): calling finalizers in ghost cycles 
can be made safe by calling each just once and then checking for 
resurrection of the cycle.

...
> +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.**
...
> +* The finalizer creates a new reference to a CI object.  This can only
> +  happen from a CI object's finalizer (see above why).  Therefore, the
> +  new reference will be detected by the GC after all CI finalizers are
> +  called (step 3 above), and collection will be aborted without any
> +  objects being broken.

I think this case should be split in two cases that have different 
answers to the question in 3 above.

A. The finalizer causes the creation of a new reference *between* a CI 
objects. Increasing the density the CI graph is not a problem. 
Collection can proceed.

B. The finalizer causes the creation of a new reference from a non-CI 
object to a CI object.  The cycle is resurrected and collection aborted.

--
Terry Jan Reedy