-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PluginDirectory: dont time out while script is modal/not cancelled #10093
Conversation
I don't see that this does fix anything. I strategy was that the scripts gets killed if it does not return within a given timeout. |
@@ -486,35 +485,26 @@ bool CPluginDirectory::WaitOnScriptResult(const std::string &scriptPath, int scr | |||
CScriptObserver scriptObs(scriptId, m_fetchComplete); | |||
if (!CGUIDialogBusy::WaitOnEvent(m_fetchComplete, 200)) | |||
{ | |||
cancelled = true; | |||
m_cancelled = true; |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
fixes regression from 95ffdcc
@FernetMenta I did not test your last iteration but if
Is true it should for sure be fixed, a 1 sec script should not take 30sec to return, specially since in my case I timeout at 30 so if there's too much data or slow network to return the JSON data it will fail 100% of the time :( Would be a big regression. |
where do you see this in the current code? the code checks if the script is still running in a loop. As soon as the script terminated the caller is not blocked anymore. |
@FernetMenta small typo it was if true, I was quoting @tamland so I supposed he have tested and report that because it was true. As I said not at home so was not able to test your iteration :) |
Having a timeout like this is not a good idea because:
|
I was referring to the 1 second wait for completion in the loop, nothing as dramatic as that;). It if ends (as opposed to complete) it's a 1 second gui delay we don't need. |
If this is always the case, I agree with you. But I don't see that this is the case. If the script brings up an additional window, the user can't cancel the busy dialog. |
Example on how to produce that? I just tried with a script opening a dialog from a plugin and it seem to work just fine. The busy dialog can be cancelled both before and after. |
I was thinking that plugins intercept user actions but this does not seem to be the case. Worst that can happen is that a user has to push back twice, first to close the dialog opened by the plugin, then to cancel the busy dialog. Is this correct? If so, you are right and an additional timeout makes indeed not much sense. |
As far as I can tell, that’s the case. So should we go with this? |
yes, please go ahead with this. |
jenkins build this please |
Complete fix for #10080. Nothing in foreground (not just modals) should time out and attempted stopped.
Also, since scripts can end at any time, it should not block the caller for such long time waiting on completion (as it did not do before, so this brings back the old behaviour).