Hi all,<br><br>Great thanks all for the feedback and detailed discussions about this problem. I'll wait before modifying the API for a while in such a scenario.<br><br>@Tomeu : Okay thanks, I'll get back to you once I try what you've told.<br>
<br>Best,<br>Hemant<br><br><div class="gmail_quote">On Mon, Jun 23, 2008 at 3:25 PM, Tomeu Vizoso <<a href="mailto:tomeu@tomeuvizoso.net">tomeu@tomeuvizoso.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Hynek,<br>
<br>
this summarizes pretty well my understanding of the issue.<br>
<br>
Indeed, OLPC is in the process of updating from F-7 to F-9, and in the<br>
later, python ships with a patch that addresses this issue. Not sure<br>
about pygobject2 and pygtk2, though.<br>
<br>
So Hemant, perhaps you would like to try an activity using the<br>
unmodified speech-dispatcher client and monitor with strace -p <pid><br>
in order to see if it's still waking up periodically? You'll have to<br>
wait a few days until the move to F9 (OLPC-3 builds) is finished,<br>
though.<br>
<br>
Thanks all,<br>
<font color="#888888"><br>
Tomeu<br>
</font><div><div></div><div class="Wj3C7c"><br>
On Mon, Jun 23, 2008 at 11:36 AM, Hynek Hanke <<a href="mailto:hanke@volny.cz">hanke@volny.cz</a>> wrote:<br>
><br>
> Hello all,<br>
><br>
> it is my impression that we are getting a bit confused here<br>
> about the various ways and their details, so I'll try to sum<br>
> up what I know.<br>
><br>
> The SSIP protocol client-server TCP protocol is partly<br>
> asynchronous. There is a request-reply scheme, but certain<br>
> data called 'events' can be delivered asynchronously at<br>
> any time. If an event is received, it is desirable to let<br>
> the client application know using some kind of callback.<br>
> Thus it is necessary for the client to monitor the server<br>
> connection at all times so that it is prepared to receive<br>
> these asynchronous events.<br>
><br>
> The current Python SSIP communication library distributed<br>
> with Speech Dispatcher uses a thread to handle the<br>
> connection. This thread is waiting at the blocking IO<br>
> (socket) for any activity and either handles it as a<br>
> reply on a command previously sent or as an asynchronous<br>
> 'event', in which case it calls a registered callback<br>
> function.<br>
><br>
> So far we have considered this as the cleanest approach,<br>
> because of the following reasons:<br>
><br>
> 1) It makes on assumptions on the internals of the<br>
> client application which uses this library other than<br>
> that it must not disturb the functioning of python threads.<br>
><br>
> 2) There is no unnecessary power consumption, the thread<br>
> in use is waiting at a blocking IO and so there is no<br>
> reason to wake it up unless there is activity on the<br>
> communication channel, in which case it is desirable.<br>
><br>
> 3) The client application does not need to do anything<br>
> to handle or ``know of'' the additional thread. The programmer<br>
> doesn't have to think of how the mainloop interacts with the<br>
> SSIP events and the whole communication.<br>
><br>
> 4) The performance (granularity, suspension) is entirely<br>
> handled by the standard mechanism of the Python threading system,<br>
> not for example by hooks to the different mainloops<br>
> of different toolkits. This mechanism exists outside the calling<br>
> program and as such is independent of the code of the calling<br>
> program (larger blocking sections etc.).<br>
><br>
> As such, this solution seems to be the simplest both<br>
> for the module and client application developer,<br>
> the best controlable in terms of performance and the<br>
> most independent of the code realization of the client<br>
> application. I do not yet really see a good technical reason<br>
> why an application would need to implement a different<br>
> mechanism, although it is very well possible there is one<br>
> and I'd like to have a discussion about this.<br>
><br>
> Now there is a problem somewhere in PyGTK and Python which<br>
> makes our thread wake up ten times a second without any<br>
> reason. There exists a patch, OLPC is not the only project<br>
> complaining and it will likely be fixed in Python 2.6.<br>
><br>
> >From what I understand so far, it really seems to me the<br>
> proper solution would be to fix Python instead of creating<br>
> bypasses in Speech Dispatcher communication library. Such<br>
> bypasses would need the library be patched AND all client<br>
> applications which happen to use pygtk+speechd changed.<br>
> For example the Orca screen reader, which is essential for<br>
> accessibility and should eventually be shiped with OLPC,<br>
> would have to be changed. Fixing Python fixes the issue<br>
> for Orca as well automatically, as well as fixing a lot<br>
> of other things.<br>
><br>
> Please let me know what do you think and most important<br>
> if there are any good technical reasons why the threading<br>
> solution is not desirable apart from the currently discussed<br>
> bug in Python or PyGTK. In such a case we could modify the<br>
> SSIPClient class to not depend on threads and inherit it into<br>
> one class that uses threads and into another one that initializes<br>
> synchronously and then hooks into a toolkit-specific mainloop.<br>
><br>
> With regards,<br>
> Hynek Hanke<br>
></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Wj3C7c">><br>
><br>
> Tomeu Vizoso píše v Ne 22. 06. 2008 v 09:39 +0200:<br>
>> On Fri, Jun 20, 2008 at 6:42 PM, Tomas Cerha <<a href="mailto:cerha@brailcom.org">cerha@brailcom.org</a>> wrote:<br>
>> > Hynek Hanke wrote:<br>
>> >> It seems to me a clearer solution to just<br>
>> >> let the speechd SSIP bindings do their work in their own thread than<br>
>> >> to extract part of the internals into your program (the socket selects).<br>
>> ><br>
>> > Yes, this would definitely be desirable, if possible.<br>
>><br>
>> The problem for us is that when pygtk is instructed to activate<br>
>> support for threads, a timer is set up that fires 10x per second. This<br>
>> is pretty bad for us, as we need to suspend as frequently as possible<br>
>> in order to save battery. This issue will be fixed in python 2.6 and<br>
>> we could be patching python 2.5 in order to avoid this, but patching a<br>
>> so basic package as python is very inconvenient for us. For more<br>
>> details, see:<br>
>><br>
>> <a href="http://blogs.gnome.org/johan/2008/01/04/enough-wakeups-in-python-programs/" target="_blank">http://blogs.gnome.org/johan/2008/01/04/enough-wakeups-in-python-programs/</a><br>
>><br>
>> >> This should be considered carefully as not to create problems later<br>
>> >> when for instance we want to switch from a text socket protocol<br>
>> >> to something else.<br>
>> ><br>
>> > Well, the `SSIPClient' will probably always implement the API over<br>
>> > sockets.  Other classes, however, may implement the same API over<br>
>> > different communication channels.  It might be interesting to think, for<br>
>> > example, how DBUS might help with respect to given problems.<br>
>><br>
>> Hmm, a D-Bus API in speech-dispatcher sounds quite interesting. As an<br>
>> alternative to threads when using a socket, asyncore might be<br>
>> interesting, although haven't looked yet at how to integrate<br>
>> asyncore's loop with pygtk's:<br>
>><br>
>> <a href="http://docs.python.org/lib/module-asyncore.html" target="_blank">http://docs.python.org/lib/module-asyncore.html</a><br>
>><br>
>> Regards,<br>
>><br>
>> Tomeu<br>
>><br>
>> _______________________________________________<br>
>> Speechd mailing list<br>
>> <a href="mailto:Speechd@lists.freebsoft.org">Speechd@lists.freebsoft.org</a><br>
>> <a href="http://lists.freebsoft.org/mailman/listinfo/speechd" target="_blank">http://lists.freebsoft.org/mailman/listinfo/speechd</a><br>
>><br>
><br>
></div></div></blockquote></div><br>