Hello, >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 problems. 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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel