GNOME Bugzilla – Bug 707708
Orca does not shut down unused synthesizers which were initialized within the preferences dialog
Last modified: 2013-09-20 12:55:06 UTC
Created attachment 254385 [details] traces of client.py.init I believe the expected behaviour is to have a single speech dispatcher. The thing happens when entering preferences. Attaching a dump produced by forcing a stack trace in __init__ of client.py from speechd.
This sounds bad.
Without using Orca: $ ps -elf | grep speech-dispatcher 0 S jd 16623 15655 0 80 0 - 28167 pipe_w 15:03 pts/2 00:00:00 grep --color=auto speech-dispatcher $ spd-say hello $ ps -elf | grep speech-dispatcher 0 S jd 16627 1 0 80 0 - 59293 pipe_w 15:04 pts/2 00:00:00 /usr/lib64/speech-dispatcher-modules/sd_dummy /etc/speech-dispatcher/modules/dummy.conf 0 S jd 16630 1 0 80 0 - 63227 pipe_w 15:04 pts/2 00:00:00 /usr/lib64/speech-dispatcher-modules/sd_flite /etc/speech-dispatcher/modules/flite.conf 0 S jd 16633 1 0 80 0 - 59296 pipe_w 15:04 pts/2 00:00:00 /usr/lib64/speech-dispatcher-modules/sd_generic /etc/speech-dispatcher/modules/generic.conf 0 S jd 16636 1 0 80 0 - 59294 pipe_w 15:04 pts/2 00:00:00 /usr/lib64/speech-dispatcher-modules/sd_cicero /etc/speech-dispatcher/modules/cicero.conf 0 S jd 16643 1 0 80 0 - 123634 pipe_w 15:04 pts/2 00:00:00 /usr/lib64/speech-dispatcher-modules/sd_espeak /etc/speech-dispatcher/modules/espeak.conf 1 S jd 16664 1 0 80 0 - 50163 poll_s 15:04 ? 00:00:00 /usr/bin/speech-dispatcher --spawn --communication-method unix_socket --socket-path /run/user/1000/speech-dispatcher/speechd.sock 0 S jd 16689 15655 0 80 0 - 28167 pipe_w 15:04 pts/2 00:00:00 grep --color=auto speech-dispatcher =================================== Are those the extra ones you are talking about? If so please file a bug against speech-dispatcher.
Joanmarie, if it is a speech-dispatcher bug, why is this code called 5 times:
+ Trace 232508
self._init()
See the original attachment.
It is initializing (not launching) all of the existing speech synthesizers speech-dispatcher claims to have: * dummy * flite * generic * cicero * espeak
(In reply to comment #4) > It is initializing (not launching) all of the existing speech synthesizers > speech-dispatcher claims to have: EDIT: Which speech-dispatcher claims to have **which have not yet been initialized** For instance, on the machine I am currently on, the synthesizer I use by default is pico. So that one (and only that one) gets initialized when I launch Orca. All the rest, AKA: > * dummy > * flite > * generic > * cicero > * espeak do not get initialized until they need to be used. If the user switches to one of the available ones from within the preferences dialog, it may get used "on the fly." My guess is that we are not waiting until selection due to a lag in response. But again, Orca is not launching five speech dispatchers. And I do not think it is a bug to initialize the synthesizers which exist. (Most certainly not a blocker bug.)
I cannot check this at the moment but if I remember correctly, that's what happens: 1. orca is starting and uses one thread to speak 2. after entering the preferences, 5 threads are run If you cannot reproduce, I'll return to it and provide python's thread dumps.
Ok, via gdb I see extra threads. I'll shutdown the unused servers after leaving preferences. They'll still get initialized, however.
Created attachment 255384 [details] [review] proposed patch From further debugging, Orca was properly cleaning up after itself (so there were no extra speech-dispatcher threads) when the settings were applied. It was failing to do this clean up when the dialog was closed via Escape, Cancel button, Clicking with the mouse. This one-line fix solves that problem. Because we are in hard code freeze now and because this has been marked a blocking bug for 3.10, I will need to request freeze break permission. NOTE: You will still see the "extra" threads when you are in the Preferences dialog. That is, again, because we are initializing the available synthesizers so that they are ready and responsive for on-the-fly changes.
BTW, I have just opened bug 708451 and will investigate whether or not it is necessary to initialize all of them and what, if any, impact there will be if we do not. I would hate to introduce a regression just before a stable release by failing to take something into account with respect to why this initialization is being done upon entering preferences.
Comment on attachment 255384 [details] [review] proposed patch The required approvals have been obtained: https://mail.gnome.org/archives/release-team/2013-September/msg00150.html https://git.gnome.org/browse/orca/commit/?id=c9dd809b19a9dc01bd399abf138ea394de4e3686