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

[Jan Kanis]

On Sat, 09 Sep 2006 12:59:23 +0200, Gustavo Carneiro  
<gjcarneiro at gmail.com> wrote:

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

Well, perhaps it isn't plausible in all cases. However, it is dependant on  
the libraries you're using and debuggable, which broken signal handlers  
apparently aren't. The approach would work if you don't use libraries that  
block threads, and if the libraries that do, co-operate with the  
interpreter. Open source libraries can be made to co-operate, and if you  
don't have the source and a library doesn't work correctly, all bets are  
off anyway.
But having the signal handler itself write to a pipe seems to be a cleaner  
solution, if it can work reliable enough for some value of 'reliable'.

Jan