Python 2.4.3 on Windows 2000, though the code in
question seems unchanged in current SVN (r46919).

I'm using Python embedded in a multithreaded C++
application. When 'import threading' is first done in
some Python script that runs in thread A, I get the
following exception when a different thread B calls
Py_Finalize():

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "C:\Python24\lib\atexit.py", line 24, in
_run_exitfuncs
    func(*targs, **kargs)
  File "C:\Python24\lib\threading.py", line 636, in
__exitfunc
    self._Thread__delete()
  File "C:\Python24\lib\threading.py", line 522, in
__delete
    del _active[_get_ident()]
KeyError: 680
Error in sys.exitfunc:
Traceback (most recent call last):
  File "C:\Python24\lib\atexit.py", line 24, in
_run_exitfuncs
    func(*targs, **kargs)
  File "C:\Python24\lib\threading.py", line 636, in
__exitfunc
    self._Thread__delete()
  File "C:\Python24\lib\threading.py", line 522, in
__delete
    del _active[_get_ident()]
KeyError: 680

The reason seems to be that the threading module uses
the thread ID of the calling thread as a key to store
its _MainThread instance on initialization, and again
the thread ID of the calling thread to delete it in its
exit function. If these two threads are not the same,
the described KeyError occurs.

I didn't study this in all detail, but it seems to me
that threading.Thread.__delete() does the wrong thing.
By doing 'del _active[_get_ident()]', it removes the
instance for the calling thread from the _active
dictionary. What it should be doing is removing *self*
from that dictionary. Is that correct?

Well, I don't think you should be calling Py_Finalize() from the non-main thread.  That just seems unsafe to me.

Regardless, though, could you write up some quick Python code that triggers this?

I'm not calling Py_Finalize from a non-main thread. What I called "thread B" is the main thread. It's the script that first imports the threading module that runs in a non-main thread (and running user-defined scripts in non-main threads is hopefully not unsafe, or there wouldn't be much point in supporting multithreading at all in Python).

It didn't even occur to me that this could be reproduced in pure Python code, so I didn't include an example in my original post. Of course, it can - see attachment. Tested on Python 2.3.5 on Mac OS X.

Thanks for the test code.  I have no clue when I or anyone else will get to this, but the report and testing code is appreciated.

threadingbug.py doesn't fail for me on trunk (linux), anyone else?

the output I get is always:

Main thread ID: -134346528
Secondary thread ID: -135349328
Exception KeyError: KeyError(-134346528,) in <module 'threading' from
'/home/gps/oss/python/trunk/Lib/threading.pyc'> ignored

I'm not sure what you mean by "doesn't fail" - from the output you quote, 
I'd say that it does fail. It's in fact the same output as I get right now 
with Python 2.5.1 on Mac OS X.

Would you classify that KeyError as expected behavior?

gah, sorry i misread the report.  you are correct.

Is the bug avoided if you import threading first and use it instead of
thread?  I'd like to see thread removed in 3.0 (renamed to _thread or
the like.)

If a python daemon thread is still running when the interpreter exits,
it is likely to fail in random ways.

Here is another example, which does not use imports.
I run the script many times, with latest version in trunk, on Windows
XP, debug build.

In the majority of runs, I get an error message:
"""
Exception in thread Thread-1 (most likely raised during interpreter
shutdown):
"""
Other tests seem to show that all modules are emptied by the cleanup
process, but the thread insists to get "time.sleep".

And more interestingly, about every 50 runs, the process segfaults...
I suspect that this is a problem similar to http://bugs.python.org/issue1856

> Is the bug avoided if you import threading first and use it instead of thread?

Yes. The bug happens when the (first) import of threading and the call to Py_Finalize() 
happen in different threads. To reproduce the problem in pure Python, I therefore have to 
use thread instead of threading to create the secondary thread. (In the C++ application, 
it's created on the C++ side.)

Has anyone checked if the solution I propose in the first post makes sense?