You mean Jython deletes instance attributes before calling __del__ ?
No. I think the term of "object resurrection" usually does not mean bringing
back a deleted object in the sense that memory was already freed.
I think it rather means that nothing referred to an object, so it was on the
"kill-list" of gc or zero-ref-count macro.
During its finalizer call, the object managed to get some reference
again. GC or zero-ref-count macro checks refcount again after the
finalizer call (doesn't it?) and then refrains from the originally triggered
deletion-task.
Where things get weired is how to treat objects (e.g. x2) that are
reachable via the original
object (e.g. x) only.
x becomes unreachable => x2 is unreachable too
CPython behavior:
free x's weakrefs, call x.__del__ => x2 is reachable again => free
memory of x; don't touch x2 at all
Java/Jython behavior:
free all weakrefs, call all finalizers of unreachable objects, i.e. call
x.__del__, call x2.__del__ (and maybe more)
=> x2 is reachable again => free memory of x; let x2 survive
(x2 even survives at least for another gc-cycle if the finalizer of x or
x2 only created a weak ref)
At least in Java/Jython case I would call x2 to be "resurrected", i.e.
its finalizer was called and weakrefs were cleared. It was on the
death-list and escaped from it. This finally brings the definition of
the word "resurrection" to its limit in language independent sense as
one can argue there was no resurrection of x2 in CPython although it's
one and the same scenario.
In which use case exactly?
The one with "indirect resurrection".
Would it have CPython behavior as sketched above or Java/Jython
behavior? (I confirmed the sketched behavior only for ref-drop-to-zero
triggered cleanup)
Best,
Stefan
On 10/27/2014 04:31 PM, Antoine Pitrou wrote:
On Mon, 27 Oct 2014 16:20:06 +0100
Stefan Richthofer <stefan.richtho...@gmx.de> wrote:
I already pointed out
"One can surely argue x2 has never been dead, or see it as
"it was killed along with x and then resurrected by x"."
In Java and thus in Jython, it is treated as the second one.
You mean Jython deletes instance attributes before calling __del__ ?
That would make most __del__ implementations quite useless...
And actually your own example would fail with an AttributeError on
"X.y = self.z".
What would still be interesting (at least when Jython 3 is born),
is which of the mentioned behaviors occurs if it is
performed by CPython's cyclic gc (consistently the first one I would guess).
In which use case exactly? :-) I've lost track a bit, since you've
posted several examples...
Regards
Antoine.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.de
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
