On 2006年9月09日 12:59:23 +0200, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 9/9/06, Jan Kanis <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com