On Fri, Jun 20, 2008 at 6:42 PM, Tomas Cerha <[EMAIL PROTECTED]> wrote: > Hynek Hanke wrote: >> It seems to me a clearer solution to just >> let the speechd SSIP bindings do their work in their own thread than >> to extract part of the internals into your program (the socket selects). > > Yes, this would definitely be desirable, if possible.
The problem for us is that when pygtk is instructed to activate support for threads, a timer is set up that fires 10x per second. This is pretty bad for us, as we need to suspend as frequently as possible in order to save battery. This issue will be fixed in python 2.6 and we could be patching python 2.5 in order to avoid this, but patching a so basic package as python is very inconvenient for us. For more details, see: http://blogs.gnome.org/johan/2008/01/04/enough-wakeups-in-python-programs/ >> This should be considered carefully as not to create problems later >> when for instance we want to switch from a text socket protocol >> to something else. > > Well, the `SSIPClient' will probably always implement the API over > sockets. Other classes, however, may implement the same API over > different communication channels. It might be interesting to think, for > example, how DBUS might help with respect to given problems. Hmm, a D-Bus API in speech-dispatcher sounds quite interesting. As an alternative to threads when using a socket, asyncore might be interesting, although haven't looked yet at how to integrate asyncore's loop with pygtk's: http://docs.python.org/lib/module-asyncore.html Regards, Tomeu _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
