Overriding Thread.join in derived class.

Graham Dumpleton Graham.Dumpleton at gmail.com
Sat Aug 18 09:31:20 CEST 2007


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




More information about the Python-list mailing list