Hi,<br><br>(This mail might become extremely verbose. Please bear with me)<br><br>The speech-dispatcher python API can be accessed at: <a href="http://cvs.freebsoft.org/repository/speechd/src/python/speechd/client.py?view=markup" target="_blank">http://cvs.freebsoft.org/repository/speechd/src/python/speechd/client.py?view=markup</a><br>
<br>The client API communicates with the speech server presently in a thread by polling the socket in the _communication() method. Whenever data is read from the socket it is added to a buffer self._com_buffer.append((code, msg, data)) and a semaphore value (self._ssip_reply_semaphore) is incremented. To read data off this buffer _recv_response(self) is called and this method is synchronized with the same semaphore self._ssip_reply_semaphore.<br>
<br>When a client instantiates a connection with the speech server a certain amount of handshaking data is shared between the client API implementation and speech server.<br><br>We are trying to eliminate the need for a thread by monitoring the socket using gobject.io_add_watch(self._socket, gobject.IO_IN, self._socket_read_cb). When the gtk mainloop is running and an input activity is observed on the socket self._socket_read_cb will be called. self._socket_read_cb in essence replicates _communication()<br>
<br>When the handshaking is taking place the gtk mainloop has not yet started and hence we cannot rely on the event generated by gobject to read data off the socket. And if this handshaking does not take place the API implementation blocks the entire process thus leading to a deadlock. Now I figured that we can allow the polling thread to exist until the handshaking takes place and then shift to the gobject method of monitoring the socket. I achieve this by defining a variable self._first_run. When the handshaking completes I make the polling thread exit (by calling close_thread(self) from the main control thread) . In this time frame I expect that the gtk mainloop will start itself (I am quite sure that it does start actually).<br>
<br>Now the main problem:<br>the gobject method does not seem to run the callback to read data from the socket when data is written to the socket. (I tried to test the socket monitoring method in a separate script and it worked fine then). If the API implementation is not able to read data from the buffer it blocks or deadlocks...<br>
<br>I am unable to determine the exact mistake that I am making. Is there something that I am missing in the way the API is implemented or is it a problem with the way i am using gobject.io_add_watch?<br><br><br>Any clues/hints ?<br>
<br>Thanks,<br>Hemant<br>