On 9/9/06, Jan Kanis <[EMAIL PROTECTED]> 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 time. Regards. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
