[Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

[Johan Dahlin]

Guido van Rossum wrote:
> On Dec 8, 2007 9:55 AM, Johan Dahlin <johan at gnome.org> wrote:
>> Guido van Rossum wrote:
>>> On Dec 8, 2007 2:17 AM, Johan Dahlin <johan at gnome.org> wrote:
>>>> Guido van Rossum wrote:
>>>>> Adam, perhaps at some point (Monday?) we could get together on
>>>>> #python-dev and interact in real time on this issue. Probably even
>>>>> better on the phone. This offer is open to anyone who is serious about
>>>>> getting this resolved. Someone please take it -- I'm offering free
>>>>> consulting here!
>>>>>
>>>>> I'm curious -- is there anyone here who understands why [Py]GTK is
>>>>> using signals anyway? It's not like writing robust signal handling
>>>>> code in C is at all easy or obvious. If instead of a signal a file
>>>>> descriptor could be used, all problems would likely be gone.
>>>> The timeout handler was added for KeyboardInterrupt to be able to work when
>>>> you want to Ctrl-C yourself out of the gtk.main() loop.
>>> Hm. How about making that an option? I don't think on the OLPC XO this
>>> is a valid use case (end users never have a console where they might
>>> enter ^C).
>>>
>> It could easily be made into a compilation option which would solve the
>> problem specifically for OLPC, but it would still be problematic for other
>> platforms important to PyGTK (linux/gnome) where console based development
>> is more common.
> 
> But do those other platforms care about the extra CPU cycles and power
> used? I suspect not, at least not to the extent that OLPC cares.

They most certainly do, pygtk applications are used in desktop software used 
on laptops where battery time is increasingly important.

Johan