[Michael Hudson]
>> I'm not sure the problem is so much that anyone _wants_ to support
>> resurrection in __del__, it's just that it can't be prevented.
[Guido]
> Well, Java has an answer to that (at least I believe Tim Peters told
> me so years ago): it allows resurrection, but will only call the
> finalizer once. IOW if the resurrected object is GC'ed a second time,
> its finalizer won't be called.
Right, that's a technical trick Java uses. Note that it doesn't stop
resurrection: all the resurrection-related pitfalls remain. One good
result is that cycles containing objects with finalizers don't stop gc
progress forever; some progress can always be made, although it may be
as little as reclaiming one object per full gc cycle (ignoring that
"full gc cycle" is a fuzzy concept in a runs-in-parallel threaded gc).
A bad result is an endless stream of nearly-impenetrable articles
encouraging deep fear of Java finalizers ;-); e.g.,
http://www.devx.com/Java/Article/30192/0/page/1
> This would require a bit "__del__ already called" on an object, but don't we
> have
> a whole word of GC-related flags?
Nope! You're probably thinking of gc_refs. That's a Py_ssize_t
today, and is overloaded to hold, at various times, a status enum
(which only needs a few bits) or a copy of the object's refcount
(which uses all the bits).
_______________________________________________
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
