-
Notifications
You must be signed in to change notification settings - Fork 192
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
Prevent JobManager UI freeze when waiting for a rule in the UI Thread #8
Comments
This was referenced Apr 12, 2022
laeubi
changed the title
A JobManager that prevents from freezing UI Thread
Prevent JobManager UI freeze when waiting for a rule in the UI Thread
May 1, 2022
I don't think we need more JobManager Customizations here, the underlying problem is more that in some circumstances the UI-Events are not driven, see for an analysis and fix.What is left is to just need to override these new methods . |
laeubi
added a commit
to laeubi/eclipse.platform.ui
that referenced
this issue
May 1, 2022
laeubi
added a commit
to laeubi/eclipse.platform.ui
that referenced
this issue
May 1, 2022
laeubi
added a commit
to laeubi/eclipse.platform.ui
that referenced
this issue
May 2, 2022
#40 is promising, I suggest we follow that track first and then we'll evaluate if we needs further smartness here and there. |
laeubi
added a commit
to laeubi/eclipse.platform.ui
that referenced
this issue
May 2, 2022
mickaelistria
pushed a commit
that referenced
this issue
May 2, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a followup of discussions in #6 and former Gerrit patch.
The general problem is that when one wants to run a job or some other operation protected by scheduling rules in UI Thread, and this scheduling rule is currently "blocked" by some other work, then the result is a UI Freeze.
We could do better by allowing the workbench/IDE parts to customize a bit the JobManager, more specifically the
beginRule
so it would show the interesting ProgressDialog when called from the UI Thread, so it doesn't seem too much like a freeze, and users have the opportunity to workaround it. It would also ease debugging.Such a solution would allow to serve multiple operations that have implemented workarounds for this freeze, such as #6 , and those workarounds could then be removed.
The text was updated successfully, but these errors were encountered: