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

[Guido van Rossum]

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.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)