[Python-Dev] bug 754449 and threads raising exceptionsat interpreter teardown

Tim Peters tim.one at comcast.net
Tue Feb 10 16:54:12 EST 2004


[Martin v. Löwis]
> Right. Shutting down a process using daemon threads should not cause
> an exception. So this is clearly a bug, or it would be one if it was
> reproducable in an example involving daemon threads.

The Zope3 test suite left a bunch of daemon threads around, and had lots of
shutdown problems in the original 2.3.  I even provoked a shutdown segfault
once by putting print stmts in the threads, trying to see what was going
wrong in them.  This is one reason I changed 2.3.3 to stop calling gc a
second time in Py_Finalize.  Other reasons are explained in a comment block
there, and an earlier comment explains how you can still provoke shutdown
exceptions easily via a different route, up to & including "Fatal Python
error".  A fundamental problem is that if just about anything gets reclaimed
during finalization, __del__ methods or weakref callbacks can get invoked,
and as soon as we're back running Python code, it's open season on the GIL,
so any number of threads can try to do anything.  Since the interpreter is
in the middle of being torn down, bad things can happen.

Armin Rigo posted a patch (on SF) moving toward using gc to tear things down
in a kinder order.  I never had time to look into that, but it sounded like
a promising approach.




More information about the Python-Dev mailing list