[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