On Sat, 09 Sep 2006 12:59:23 +0200, Gustavo Carneiro email@example.com wrote:
On 9/9/06, Jan Kanis firstname.lastname@example.org 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.
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'.