Hi,<br><br>Thank you all for your ideas.<br><br>@Tomeu : I looked into the gobject.idle_add and luckily Tomas has an example for me too :). I will be trying that out next.<br><br>@Tomas:<br><br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">I was facing a similar problem there and I solved it by passing all callbacks to the gidle thread.  All SD communication is performed from the GUI thread, but the callbacks don't perform any actions themselves -- they only schedule these actions to be performed within the idle thread.  It works surprisingly well.</blockquote>


<div><br>Hmmm, would this mean that if I got a WORD_SPOKEN event notification then the callback to be executed for this event will be executed immediately? If that happens then I guess the solution would be pretty nice. Could it be possible that such event notifications become queued and get executed much after the word has been spoken ? (Developers in the OLPC community would be very interested in providing a karaoke style hightlight effect during speech synthesis in their gtk activities).<br>


<br>@Hynek:<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This really seems like the former problem with socket functions<br>
behaving in a strange way in threads with pygtk unless the<br>
gtk.gdk.threads_init() is called. The current sample implementation<br>
you've sent in the attachment still partly uses threads (through speechd)<br>
but doesn't call this function, which now looks likely to cause the problems.</blockquote><div> </div><div>Precisely it is and the OLPC community would be interested in providing the solution to the problem at the API layer instead for two reasons :<br>
<ol><li>Simplifying the process for the activity developer</li><li>Avoiding the use of threads <br></li></ol></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


Now, what are the reasons why you want to avoid using threads?<br> </blockquote><div><br>I had a discussion in the olpc irc channel and the reason for avoiding threads given was that the laptop uses a Suspend and Resume feature for power saving and using threads within the gtk activity would prevent the laptop from suspending.<br>


<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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. Because if I understand correctly, the proposed<br>
solution would necessarily be based on exporting the socket file<br>
descriptors in use to the client program.</blockquote><div><br>The present diff that I have provided does *not* expose the socket to the client program. It simply uses the speechd thread for handshaking and shifts to async communication after that... (It does not work thats a different thing..)<br>


<br></div></div>I will try using the gobject.idle_add approach next and see if I make any headway in that direction now.<br><br>Thanks,<br>Hemant<br>