Making speech-dispatcher python API support asynchronous socket communication

Tomeu Vizoso tomeu at tomeuvizoso.net
Sun Jun 22 03:39:23 EDT 2008


On Fri, Jun 20, 2008 at 6:42 PM, Tomas Cerha <cerha at brailcom.org> 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



More information about the Devel mailing list