[Python-Dev] Signals, threads, blocking C functions

Jan Kanis jan-python at maka.demon.nl
Sat Sep 9 04:07:02 CEST 2006


At the risk of waking up a thread that was already declared dead, but  
perhaps this is usefull.

So, what happens is pythons signal handler sets a flag and registrers a  
callback. Then the main thread should check the flag and make the callback  
to actually do something with the signal. However the main thread is  
blocked in GTK and can't check the flag.

Nick Maclaren wrote:
...lots of reasons why you can't do anything reliably from within a signal  
handler...

As far as I understand it, what could work is this:
-PyGTK registrers a callback.
-Pythons signal handler does not change at all.
-All threads that run in the Python interpreter occasionally check the  
flag which the signal handler sets, like the main thread does nowadays. If  
it is set, the thread calls PyGTKs callback. It does not do anything else  
with the signal.
-PyGTKs callback wakes up the main thread, which actually handles the  
signal just like it does now.

PyGTKs callback could be called from any thread, but it would be called in  
a normal context, not in a signal handler. As the signal handler does not  
change, the risk of breaking anything or causing chaos is as large/small  
as it is under the current scheme. However, PyGTKs problem does get  
solved, as long as there is _a_ thread that returns to the interpreter  
within some timeframe. It seems plausible that this will happen.


More information about the Python-Dev mailing list