[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Making speech-dispatcher python API support asynchronous socket communic

From: Hynek Hanke
Subject: Making speech-dispatcher python API support asynchronous socket communication
Date: Fri, 20 Jun 2008 16:52:45 +0200


 >Now the main problem:
 >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...

This really seems like the former problem with socket functions
behaving in a strange way in threads with pygtk unless the
gtk.gdk.threads_init() is called. The current sample implementation
you've sent in the attachment still partly uses threads (through speechd)
but doesn't call this function, which now looks likely to cause the 

Now, what are the reasons why you want to avoid using threads?
I thought the former problem with strange behavior of recv() was
solved by the above function. 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).

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. Because if I understand correctly, the proposed
solution would necessarily be based on exporting the socket file
descriptors in use to the client program.

This is just my thoughts at the moment. I'm not entirely clear
about what are the exact concerns and what would be the best
way forward, so I'm open to explanations and suggestions. If there
is a good reason to avoid threads, we should look for a way to do it.

With regards,
Hynek Hanke

reply via email to

[Prev in Thread] Current Thread [Next in Thread]