Module cleanup improvement
Hi all, Bug #1717900 has an example of a script that causes a (cryptic, IMO) error during module cleanup since instances of a class just happen to get destroyed after their class is destroyed, and the __del__ method manipulates a class attribute. As I understand it this is expected under the behavior outlined here: http://www.python.org/doc/essays/cleanup/ Adding a step C1.5 which removes only objects that return true for PyInstance_Check seems to prevent the problem exhibited by this bug (I tried it out locally on the trunk and it doesn't cause any problems with the regression test suite). Is there any reason that adding such a step to module cleanup would be a bad idea? Alan
Hi Alan, On Mon, May 21, 2007 at 08:17:02PM -0400, Alan McIntyre wrote:
Adding a step C1.5 which removes only objects that return true for PyInstance_Check seems to prevent the problem exhibited by this bug (I tried it out locally on the trunk and it doesn't cause any problems with the regression test suite). Is there any reason that adding such a step to module cleanup would be a bad idea?
On another level, would there be interest here for me to revive my old attempt at throwing away this messy procedure, which only made sense in a world where reference cycles couldn't be broken? Nowadays the fact that global variables suddenly become None when the interpreter shuts down is a known recipe for getting obscure messages from still-running threads, for example. This has one consequence that I can think about: if we consider a CPython in which the cycle GC has been disabled by the user, then many __del__'s would not be called any more at interpreter shutdown. Do we care? A bientot, Armin
On another level, would there be interest here for me to revive my old attempt at throwing away this messy procedure, which only made sense in a world where reference cycles couldn't be broken?
I definitely think Py3k, at least, should use such an approach - especially with PEP 3121, which should allow to incorporate variables stored in extension module's "globals" to participate in GC. Regards, Martin
[Armin Rigo]
On another level, would there be interest here for me to revive my old attempt at throwing away this messy procedure, which only made sense in a world where reference cycles couldn't be broken?
Definitely.
Nowadays the fact that global variables suddenly become None when the interpreter shuts down is a known recipe for getting obscure messages from still-running threads, for example.
This has one consequence that I can think about: if we consider a CPython in which the cycle GC has been disabled by the user, then many __del__'s would not be called any more at interpreter shutdown. Do we care?
I don't believe this is a potential issue in CPython. The user-exposed gc.enable() / gc.disable() only affect "automatic" cyclic gc -- they flip a flag that has no bearing on whether an /explicit/ call to gc.collect() will try to collect trash (it will, unless a collection is already in progress, & regardless of the state of the "enabled" flag). Py_Finalize() calls the C spelling of gc.collect() (PyGC_Collect), and I don't believe that can be user-disabled.
Armin Rigo wrote:
if we consider a CPython in which the cycle GC has been disabled by the user, then many __del__'s would not be called any more at interpreter shutdown.
That can happen now anyway. Module clearing only cleans up cycles that go through the module dict. +1 from me on getting rid of module clearing at shutdown. -- Greg
participants (5)
-
"Martin v. Löwis" -
Alan McIntyre -
Armin Rigo -
Greg Ewing -
Tim Peters