If one creates a thread using threading.Thread and makes it a daemon by calling setDaemon(), then when Python is exiting it will not attempt to call join() on that thread and wait for it to complete first.
The problem with this is that the daemonised thread will continue to run while atexit register callbacks are being called and while Python is being subsequently destroyed The result is that the daemonised thread may access application components that have been cleaned up and in the worst case as Python progresses with destroying interpreters it could try accessing things like sys.modules which may no longer exist. End result is that it could result in a Python exception at some point, evidenced by messages starting with: Exception in thread Thread-1 (most likely raised during interpreter shutdown) or: Unhandled exception in thread started by <bound method Thread.__bootstrap of <Thread(Thread-1, started daemon)>> In order to avoid this, do people think that as an alternative to creating daemonised thread that it would be reasonable to create a derived Thread class for the particular task which overrides Thread.join() method to set some flag or otherwise take some action that the thread would notice to tell it to stop, and then call base class Thread.join(). This way you can flag the thread to shutdown automatically when Python is going around calling join() on non daemonised threads. Or am I missing the obvious as far as ways of flagging threads to tell them to stop? Note that this is where Python is being used embedded in a C program. There is no Python main function where code can be put to signal threads to otherwise stop. Graham -- http://mail.python.org/mailman/listinfo/python-list
