[Python-Dev] threading bug?

[Tim Peters]

[Thomas Heller]
> Unhandled exception in thread:
> Traceback (most recent call last):
>   File "c:\python21\lib\threading.py", line 393, in __bootstrap
>     self.__stop()
>   File "c:\python21\lib\threading.py", line 399, in __stop
>     self.__block.notifyAll()
>   File "c:\python21\lib\threading.py", line 235, in notifyAll
>     self.notify(len(self.__waiters))
>   File "c:\python21\lib\threading.py", line 217, in notify
>     me = currentThread()
> TypeError: object of type 'None' is not callable
>
> This traceback does not appear when I register an atexit
> function to stop the thread.

We're missing basic info, like which OS and which Python release.  More than
one shutdown race has been fixed over the decades <wink>.

I've seen reports of this before, but under older Pythons, and/or in
conjunction with running GUIs where the problem went away if the GUI was
taken out of the equation.  AFAIK, nobody ever stuck with it long enough to
track down the real cause, though.

This relatively recent comment in pythonrun.c's Py_Finalize() is probably
relevant:

/* The interpreter is still entirely intact at this point, and the
 * exit funcs may be relying on that.  In particular, if some thread
 * or exit func is still waiting to do an import, the import machinery
 * expects Py_IsInitialized() to return true.  So don't say the
 * interpreter is uninitialized until after the exit funcs have run.
 * Note that Threading.py uses an exit func to do a join on all the
 * threads created thru it, so this also protects pending imports in
 * the threads created via Threading.
 */
call_sys_exitfunc();
initialized = 0;


I expect that a *foreign* thread (== one not created by threading.py) isn't
going to be waited for by threading.py's exit func .join(), and if so won't
be protected by this mechanism (that's a shutdown race we can't really do
anything about -- we've got no handle on what foreign threads do).