Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
fix PluginDirectory #9778
Although the Search YouTube hang appeared to be resolved, it's possible this PR is causing other odd behaviour when starting addons (or it's another hangover from the original problem, #9664).
With PR9778, sometimes the user interface for the addon will "flash" (appear briefly then disappear), other times the addon will simply show a blank background (but the GUI hasn't hung - "Back" will eventually return to the Estuary Home menu).
I can reproduce this with latest master + PR9778 and YouTube addon in Ubuntu when running Estuary Home > Addons > YouTube.
Another addon showing similar problems is the Amazon Prime Instant addon.
In fact when you run the Amazon Prime Instant addon you see only a blank background. Click "Back" and you see a constantly spinning "Busy" icon. Click "Back" again and you're returned to the Estuary Home menu. Now click on Search > Search YouTube and you'll be shown the Amazon Prime Instant addon screen overlaid with a "Busy" dialog...
For example the YouTube addon? Yes I see that, first "Back" (or Cancel) shows a busy dialog. Strangely I don't get this issue with Global Search, so I assumed it was specific to the YouTube addon (ie. searching for
May 10, 2016
I dunno if it's caused by this commit, but the busy dialog could break skin based mechanism on startup.
I don't believe this is a case of plugins 'hijacking' the main thread, but rather when a list is filled directly from a plugin (
If plugins are now returning their contents on the main thread, then this would appear to be a change of behaviour leading to a regression in terms or usability, and not the result of any change in the plugin api - and affects all plugins I have tested.
(And if it is otherwise, then the team need to inform most every plugin author of the changes to the api that allow them to do the work they need to do in a background thread, as has automatically happened up to this point when directly filling the contents of a list, or the previous posters statement needs to be redacted)
@FernetMenta i will try that - but as far as I can tell the scriptobs object goes out of scope right after the abort is called which means the DTOR of the Thread is called which in turn already does a "StopThread" which waits for the threads exit. So if I got it right - between calling abort and continuation in the upper code layer there is already an implicit wait for the threads exit in the CThread DTOR.
This is the line where the scriptObs is going out of scope leading to the DTOR calling StopThread.