From: "Guido van Rossum" <guido@python.org> > > [Apologies, I also asked this on c.l.p, but got no > > answer so far. I have not too much time left before > > I will be away for nearly 2 weeks] > > > > I wonder if this is a bug. I'm running a deamon thread doing > > some work in the background, and sometimes when Python exits > > I get tracebacks like this: > > > > 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. > > > > Is this a bug? Aren't daemon threads supposed to clean up > > themselves? > > This is probably a result of the destructive module finalization. > When Py_Finalize() is called, threads that are still running are not > killed. But Py_Finalize() replaces the values of all globals in > modules with None (it could just clear the module's dictionary but > there was some reason for doing it this way) and that is what you are > probably seeing. > > If there was a primitive to kill a thread, we might use it in > Py_Finalize() -- but there isn't (it's been requested but it's hard to > see how to do it safely). But it seems the system is trying to stop the thread(s), maybe too late. In my case, atexit.register(self.stop) makes a clean shutdown. My point is: should the threading module do this? I can easily live with doing it myself - I just don't know if this is intended or required. Thomas
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4