Making speech-dispatcher python API support asynchronous socket communication
Hynek Hanke
hanke at brailcom.org
Mon Jun 23 04:39:17 EDT 2008
>> 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.
As I understand the problem, either no threads are used at all or
the pygtk thread initialization method must be called (which causes
the described problems regardless of whether any threads are currently
running or not. I wouldn't mix the two approaches as that doesn't seem
to resolve the issue and is likely to cause additional problems. Consider
for example that you might need to restart the connection to Speech
Dispatcher in some situations.
So if we want to bypass the pygtk threading bug, we must use no
threads at all with pygtk. I think it is possible to avoid threads
entirely and use the gtk loop instead. The SSIP communication is
only asynchronous because of callbacks, all other parts are completely
synchrounous, and it is possible to rely on the fact that no callbacks
will be delivered until the first speech request is sent. So the handshaking
part can be implemented without threads.
> I guess that the speechd maintainers don't wish to add a gobject
> dependency to their packages, right? If the python API exposed the
> socket and a couple of functions, the caller could be responsible for
> providing integration with whatever main loop it wishes to use
> (gobject or qt, for example).
Well, the patch that was sent to this mailing list doesn't
technically introduce any new dependency, as the toolkit specific
modules are only imported upon request. It must however
be considered that it introduces additional gtk specific code
which will have to be maintained.
With regards,
Hynek Hanke
More information about the Devel
mailing list