Module gets garbage collected; its globals become None

Steven Taschuk staschuk at telusplanet.net
Sat May 24 10:57:32 EDT 2003


Quoth Martin v. Löwis:
  [...]
> However, the expectation still is that modules live until the end,
> with the exception of reloaded modules (which even carry over the
> dictionary). This is the typical case, so whatever change is made,
> breakage of the shutdown code is probably unacceptable.

Absolutely; I don't mean to imply otherwise.

  [...]
> Talking about bogus ideas: leaving collection of modules to cyclic gc
> is bogus as well. A global object might have a finalizer and a cycle
> with its module. Currently, such an object gets finalized at
> shutdown. Cyclic gc alone would move it into gc.garbage instead of
> finalizing it.

Yes, I see your point.  But this does suggest an approach which
could be taken during shutdown -- act like an application and
analyze gc.garbage.  That is, clear sys.modules, invoke the cyclic
gc, scan gc.garbage for module dicts, clear any such dicts, clear
gc.garbage, and invoke the cyclic gc again.  (This assumes it's
possible to distinguish module dicts from other dicts, which might
take some trickery.  And no doubt there'd be some special-casing
for sys and __builtin__, as there is presently.)

Under such a scheme, I don't think there'd be a need for
module_dealloc to call _PyModule_Clear; the dicts would be cleared
as part of the special shutdown procedure instead.  Thus modules
would still get their cycle-breaking treatment during shutdown,
but those which get finalized during normal execution wouldn't
nuke their namespaces, so orphaned objects would continue to work.

How does that sound?

-- 
Steven Taschuk                             staschuk at telusplanet.net
"I may be wrong but I'm positive."  -- _Friday_, Robert A. Heinlein





More information about the Python-list mailing list