speak() in python ignoring callback (for BEGIN)

[Richard Schwarting]

My sleep(1) didn't work, so I have a slightly different solution: I
cache the callback I want called in a separate location, so that if it
isn't added to _callbacks in before that gets checked, the code that
executes the callbacks can check to see if the cached-in-advance copy
is around to call.

Neither of those are really good solutions, but the logic seems more
messed up than I thought:

* _SSIP_Connection has a method *_communicate* listening for incoming
connections in its *own thread*.  When received data is not an index
mark or an event, it release()s _ssip_reply_semaphore and skips back
to the top of the loop.

* Client.speak() uses _SSIP_Connection.send_data() to send stuff that
will be received by the *_communicate* listener thread.   send_data()
*WAITS* on _ssip_reply_semaphore to know that it has received a
response, from which it will extract the msg_id for data it sent out.

Client.speak() really wants that msg_id from send_data() so it can
attach the callback it needs executed to the msg_id via
_callbacks[msg_id] = (callback, ...), in anticipation that
_SSIP_Connection in _callback_handler() will look for the callback
there, and call it.

* TRAGICALLY, for CallbackType.BEGIN, this almost never works out.
It's almost impossible for Client.speak() to get the msg_id in time to
associate the callback before _SSIP_Connection's _communicate has
called its _callback_handler.  This is in large part because
send_data() is STILL WAITING on _ssip_reply_semaphore!  _communicate
is totally under way before send_data() has the response it needs
including the msg_id.  send_data() often won't return until after
_communicate() is done and is handling the subsequent "OK MESSAGE
QUEUED".  Only after that (way too late, now that the callback was
found to be missing), can Client.speak() associate the callback with
the msg_id (in time for the END and CANCEL events).

==Work around==

Yah, so right now, before calling _conn.send_data(), I'm setting
self._cached_callback = (callback, events), and in Connection's
_callback_handler, if one isn't found for the msg_id, I'm hoping that
the _cached_callback is recent enough...

==Question==

Is this a common problem?  Do people just not write code that needs to
know when CallbackType.BEGIN occurs?  Perhaps my system is poorly
configured?  The provided _test.py also encountered a failure with the
assert on callbacks.

On Mon, Apr 6, 2009 at 21:49, Richard Schwarting <aquarichy at gmail.com> wrote:
> Hello.
>
> For the Python support, in src/python/speechd/client.py, in speak(),
> there's this nice little section:
>
> ===========================================
> ? ? ? ?result = self._conn.send_data(text)
> ? ? ? ?if callback:
> ? ? ? ? ? ?msg_id = int(result[2][0])
> ? ? ? ? ? ?# TODO: Here we risk, that the callback arrives earlier, than we
> ? ? ? ? ? ?# add the item to `self._callbacks'. ?Such a situation will lead to
> ? ? ? ? ? ?# the callback being ignored.
> ? ? ? ? ? ?self._lock.acquire()
> ? ? ? ? ? ?try:
> ? ? ? ? ? ? ? ?self._callbacks[msg_id] = (callback, event_types)
> ? ? ? ? ? ?finally:
> ? ? ? ? ? ? ? ?self._lock.release()
> ? ? ? ?return result
> ===========================================
>
> The issue described there is very real. ?I have an application that
> relies on knowing when the speech stream is supposed to have actually
> begun (it's not appropriate to just assume it has just because I
> called speak()), so on slightly faster systems or after the first few
> runs (because more is in memory or optimised?), the callback gets
> missed virtually all the time :|
>
> I filed a bug with my distro (Fedora):
> https://bugzilla.redhat.com/show_bug.cgi?id=494298
>
> If someone has an idea what the proper solution would be (wait around
> in a thread for the value to show up? - right now I've simply added a
> second-long sleep locally (ugh)), I don't mind going about
> implementing + testing it next weekend.
>
> Cheers,
> ?Richard Schwarting
>