Signal Handling In Python
Solution 1:
Mixing signals and threads is always a little precarious. What you describe should not happen, however. Python only handles signals in the main thread. If the OS delivered the signal to another thread, that thread may be briefly interrupted (when it's performing, say, a systemcall) but it won't execute the signal handler. The main thread will be asked to execute the signalhandler at the next opportunity.
What are your threads (including the main thread) actually doing when you send the signal? How do you notice that they all 'stop'? Is it a brief pause (easily explained by the fact that the main thread will need to acquire the GIL before handling the signal) or does the process break down entirely?
Solution 2:
I'll sort-of answer my own question: In my first attempt at this I was using time.sleep(run_time) in the main thread to control how long the threads ran until they were stopped. By adding debug I could see that the sleep loop seemed to be exiting as soon as the signal handler returned so everything was shutting down normally but early!
I've replaced the sleep with a while loop and that doesn't jump out after the signal handler returns so my threads keep running. So it solves the problem but I'm still a bit puzzled about sleep()'s behaviour.
Solution 3:
You should probably use a threading.Condition variable instead of sending signals. Have your main thread check it every loop and perform its special operation if it's been set.
If you insist on using signals, you'll want to move to using subprocess instead of threads, as your problem is likely due to the GIL.
Solution 4:
Watch this presentation by David Beazley.
It also explains some quirky behavior related to threads and signals (Python specific, not the general quirkiness of the subject :-) ).
http://pyprocessing.berlios.de/ Pyprocessing is a neat library that makes it easier to work with separate processes in Python.
Post a Comment for "Signal Handling In Python"