-
Notifications
You must be signed in to change notification settings - Fork 229
Use a Job as the Reconciler Thread for AbstractReconciler #3025
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
Conversation
|
I was able to reproduce the problem you described and with this change the job continues to run which avoids the described problem. In addition, I see that the editor starts with error markers that are subsequently cleaned up... |
|
This pull request changes some projects for the first time in this development cycle. An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch. Git patchFurther information are available in Common Build Issues - Missing version increments. |
laeubi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thant for catching up with this, ignoring the cancel request seems like a reasonable approach here, maybe we even want to override cancel() of the job and make it a noop with a comment why it is done here that way.
For our safety and comfort, that's not possible. 😁 |
iloveeclipse
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks better now, except two places.
I guess we might see some test hangs or slowdown because of that change for tests that open editors and do waitForJobs(), we will see...
Ideally if we submit that it would be after we have at least one "green" build in SDK.
bundles/org.eclipse.jface.text/src/org/eclipse/jface/text/reconciler/AbstractReconciler.java
Show resolved
Hide resolved
bundles/org.eclipse.jface.text/src/org/eclipse/jface/text/reconciler/AbstractReconciler.java
Outdated
Show resolved
Hide resolved
|
All the failures seem related to an unrelated API filter problem: |
@raghucssit : I guess it's same issue you mentioned? |
|
I'll look at fixing that API issue too, but it's hard to juggle back and forth. Also Ant current has errors in my workspace and Maven Publishing stopped working. Too many fires to fight. 😱 So if you're okay with the current content of this PR, maybe we could clear it out of the way? |
bundles/org.eclipse.jface.text/src/org/eclipse/jface/text/reconciler/junk
Outdated
Show resolved
Hide resolved
Currently AbstractReconciler uses a raw thread for reconciling requests. This has the problem that if the job framework is suspended (e.g, during startup of the IDE) some code is still executed because the reconciler is called from the creation of the text viewer and starts immediately. This replaces the bare thread with a job but retains current behaviour. Note that the job cannot be manually terminated, just as the thread continued to run indefinitely until explicitly terminated. eclipse-platform#3018
|
Hopefully it builds this time with no failures! |
|
We even have a green build now. 😁 |
iloveeclipse
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ed, please check SDK test results on the next SDK build. I fear there could be some hangs.
|
I will look at the builds tomorrow. |
|
FYI, I started this build: https://ci.eclipse.org/releng/job/Builds/job/I-build-4.37/14/ |
- This ensures that the tests don't leak jobs that are only detected by a subsequent test. - Use editor.close(false) rather than editor.dispose() to clean up the thread/job properly. eclipse-platform#3025
- This ensures that the tests don't leak jobs that are only detected by a subsequent test. - Use editor.close(false) rather than editor.dispose() to clean up the thread/job properly. #3025
Not so nice workaround for eclipse-jdt#721. After eclipse-platform/eclipse.platform.ui#3025 every opened editor means there will be a reconciler job running, which is not what we do NOT want to wait for. AbstractReconciler.class is the family object we can check for, so add that family to the list of excluded jobs we don't care.
After eclipse-platform/eclipse.platform.ui#3025 every opened editor means there will be a reconciler job running, which is not what we do NOT want to wait for. AbstractReconciler.class is the family object we can check for, so add that family to the list of excluded jobs we don't care. Added getUsualJobFamiliesToIgnore() and changed waitForJobs() to use that by default if nothing else is given. Fixes eclipse-jdt#721
After eclipse-platform/eclipse.platform.ui#3025 every opened editor means there will be a reconciler job running, which is not what we do NOT want to wait for. AbstractReconciler.class is the family object we can check for, so add that family to the list of excluded jobs we don't care. Added getUsualJobFamiliesToIgnore() and changed waitForJobs() to use that by default if nothing else is given. Fixes #721
|
Probably related regression: eclipse-jdt/eclipse.jdt.ui#2323 |
After eclipse-platform/eclipse.platform.ui#3025 every opened editor means there will be a reconciler job running, which is not what we do NOT want to wait for. AbstractReconciler.class is the family object we can check for, so add that family to the list of excluded jobs we don't care. Added getUsualJobFamiliesToIgnore() and changed waitForJobs() to use that by default if nothing else is given. Fixes #721


Currently AbstractReconciler uses a raw thread for reconciling requests. This has the problem that if the job framework is suspended (e.g, during startup of the IDE) some code is still executed because the reconciler is called from the creation of the text viewer and starts immediately.
This replaces the bare thread with a job but retains current behaviour. Note that the job cannot be manually terminated, just as the thread continued to run indefinitely until explicitly terminated.
#3018