[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Problems with "end" callback in Python
From: |
Hynek Hanke |
Subject: |
Problems with "end" callback in Python |
Date: |
Mon, 14 Apr 2008 14:33:41 +0200 |
> The code is attached. This is not an OLPC Activity but a standalone
> program I use to try out new features
Hello James,
I have tried to run the code you've sent and I can reliably reproduce
the issue. I believe it has something to do with the way how you call
speechd.client.speak() from inside the gtk loop, because outside of it,
everything works normally (even in your application).
I'm not familiar with PyGTK however, so I don't see what exactly is
going wrong. I'll try to describe my findings in hope you or someone
else will have someidea.
As you describe, in your program, the SSIP Python interface often fails
to deliver a callback to the client application (in fact, it freezes and
no other communication with Speech Dispatcher is possible). The exact
reason is that in self._socket.recv(1024) (socket.socket.recv()) fails
to return although the logs of Speech Dispatcher prove some new data
have been written to the socket.
I found that this happens when cb_next_word is
called as a callback from keypress_cb() via
timeout_id = gobject.timeout_add(100, self.next_word_cb)
but it doesn't happen, if I call it directly (around line 75):
self.karaoke = True
self.finished_flag = True
#timeout_id = gobject.timeout_add(100,
self.next_word_cb)
while True:
self.next_word_cb()
time.sleep(0.1);
return True
This variant will reliably speak the whole document word-by-word with
all the expected callbacks received.
Another interesting observation is that the mentioned _socket.recv(1024)
returns and correctly receives all the pending callbacks just after I
hit CTRL-C on the python interpreter running ReadETextsActivity.py and
thus kill the main program thread.
Now, the _socket.recv() function in the python speechd library runs in a
separate thread that is being launched from the Client object
constructor. So apparently gobject.timeout_add() somehow disturbs socket
opperations in other threads.
It seems really strange to me and quite unlikely that the python
bindings themselves would be responsible.
With regards,
Hynek Hanke
- Problems with "end" callback in Python, James Simmons, 2008/04/11
- Problems with "end" callback in Python, Milan Zamazal, 2008/04/11
- Problems with "end" callback in Python, James Simmons, 2008/04/11
- Problems with "end" callback in Python,
Hynek Hanke <=
- Problems with "end" callback in Python, James Simmons, 2008/04/14
- Problems with "end" callback in Python, James Simmons, 2008/04/17
- Problems with "end" callback in Python, Hemant Goyal, 2008/04/18
- Problems with "end" callback in Python, James Simmons, 2008/04/18
- Problems with "end" callback in Python, Hynek Hanke, 2008/04/18
- Problems with "end" callback in Python, James Simmons, 2008/04/18
- Problems with "end" callback in Python, Lukas Loehrer, 2008/04/20
- Problems with "end" callback in Python, Hynek Hanke, 2008/04/21
- Problems with "end" callback in Python, James Simmons, 2008/04/22
- Problems with "end" callback in Python, Hynek Hanke, 2008/04/23