Despite having a notion of a 'daemon thread', python's behavior around it is
remarkably poor. The point of a daemon is that it can be safely reaped during
interpreter shutdown, but if one *actually* exists python screams like you're
kicking it on the balls.
*sigh*
So anyway, it's important to be sure all threads are joined on before shutting
down. Generally Stem is good about this but forgot that state change
notifications spawn their own untracked daemons.
As a result if you've registered any state listeners you'll have a good chance
of a stacktrace. What happens is as follows...
* You call close() on the controller.
* Closing sends a notification in a new thread to your listener to say that
it's closing.
* Before that thread finishes the interpreter shuts down and wails like a
baby.
As such, we now track these daemons and close() joins on them before returning.
This was caught thanks to frequent arm stacktraces like...
Exception in thread Closed notification (most likely raised during interpreter shutdown):
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 551, in __bootstrap_inner
File "/usr/lib/python2.7/threading.py", line 504, in run
File "/home/atagar/Desktop/seth/seth/header_panel.py", line 372, in reset_listener
File "/home/atagar/Desktop/seth/seth/header_panel.py", line 376, in _update
File "/home/atagar/Desktop/seth/seth/header_panel.py", line 403, in get_sampling
File "/home/atagar/Desktop/seth/stem/control.py", line 392, in wrapped
File "/home/atagar/Desktop/seth/stem/control.py", line 1445, in get_pid
File "/home/atagar/Desktop/seth/stem/util/system.py", line 328, in pid_by_name
File "/home/atagar/Desktop/seth/stem/util/system.py", line 930, in call
File "/usr/lib/python2.7/subprocess.py", line 754, in communicate
File "/usr/lib/python2.7/subprocess.py", line 1312, in _communicate
File "/usr/lib/python2.7/subprocess.py", line 1373, in _communicate_with_poll
<type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'POLLOUT'