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

Gustavo Carneiro gjcarneiro at gmail.com
Sat Sep 9 12:59:23 CEST 2006

On 9/9/06, Jan Kanis <jan-python at maka.demon.nl> wrote:
> 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.

  No, it is not plausible at all.  For instance, the GnomeVFS library
usually has a pool of thread, not doing anything, waiting for some VFS
task.  It is likely that a signal will be delivered to one of these
threads, which know nothing about Python, and sit idle most of the


More information about the Python-Dev mailing list