GC and finalizers [was: No destructor]

[Martin von Loewis]

Paul Duffin <pduffin at hursley.ibm.com> writes:

> A little picture describing the cycle would be useful.

Maybe, yes. However, people participating in this thread should have
no problems following a few lines of Python code.

> The clean up sequence would have to be something more like.
> 
> 	__del__ is called for all objects in the cycle.

In what order? What if one invocation of __del__ restores the entire
cycle back to life?

> 	If any objects now have external references then the garbage
> 	collection is over.

What if there are other objects living in cycles (but different
cycles)?  Do you know an efficient algorithm (in time and space) that
computes all objects in a cycle?

> h.next.item is obviously a reference to an object so assuming that it
> is the only reference to the object when the dict is cleared the
> reference will go and the resource object will be freed and should clean
> itself up.

No, it is an external reference. h.next.item was meant as an integer
object (so it is still an object, just not an instance object); releasing
this integer will *not* release the resource.

[I'm having difficulties to parse the next sentence, please correct
 me if I broke it up in the wrong spots.]

> Am I right in saying that because Python does not prevent external accesses
> to an object that any object could be the cause of a cycle 

It is true that any instance object could be the cause of a cycle,
yes.  I don't know whether the ability to external access is the
cause; I'd rather think it is not.

> so every __del__ function would have to check that any external
> objects it was referencing were still valid, i.e. not just deleted.

In current Python, no object has to check whether something it
references is deleted - objects that are still referenced are never
deleted.

> Because the instance dictionaries would not be cleared until all
> __del__ functions had been called then self.next.item exists when
> Head.__del__ is called. It should probably also check that self.next
> and self.next.item are valid anyway.

Calling all finalizers first before clearing any object causes
different problems. How do you deal with reference counting then?
Given a single finalizer

def __delf__(self):
   self.next = None

how do you deal with the DECREF of the old value of self.next? It used
to be 1, before collection started; it then goes to zero. Normally,
you should call the finalizer of the object now. However, you may have
called that already, as self.next may have been found earlier in the
cycle. What do you do?

Martin