-
Notifications
You must be signed in to change notification settings - Fork 115
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
Add test to JobGroupTest #675
Add test to JobGroupTest #675
Conversation
79efc2e
to
430ac3b
Compare
I'm a bit baffled about this error (it happens under Linux):
It doesn't say much. Any ideas what could it be or how to fix it? |
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.
The added test randomly fails due to multiple race conditions. In particular, there is no order of the jobs to be executed, so cancelling the job group once a job with a specific number is executed does not give any guarantee regarding the number of jobs that have run in the end.
To reproduce a failure due to a race condition, add a sleep of several milliseconds into the if clause of the run method. The test will constantly fail.
...sts/org.eclipse.core.tests.runtime/src/org/eclipse/core/tests/runtime/jobs/JobGroupTest.java
Outdated
Show resolved
Hide resolved
...sts/org.eclipse.core.tests.runtime/src/org/eclipse/core/tests/runtime/jobs/JobGroupTest.java
Outdated
Show resolved
Hide resolved
...sts/org.eclipse.core.tests.runtime/src/org/eclipse/core/tests/runtime/jobs/JobGroupTest.java
Outdated
Show resolved
Hide resolved
...sts/org.eclipse.core.tests.runtime/src/org/eclipse/core/tests/runtime/jobs/JobGroupTest.java
Outdated
Show resolved
Hide resolved
430ac3b
to
6cf0bbe
Compare
6cf0bbe
to
baa0a8e
Compare
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.
I propose the usage of a barrier instead of multiple latches for the reasons I give in the code comment.
In addition, the current implementation does not guarantee that all jobs are finished when the test finishes, as waitForCompletion
has a timeout and may leave the jobs running. Using a barrier that waits in the main thread for at least the time the jobs themselves wait on that barrier avoids that risk.
...sts/org.eclipse.core.tests.runtime/src/org/eclipse/core/tests/runtime/jobs/JobGroupTest.java
Outdated
Show resolved
Hide resolved
baa0a8e
to
3b64a07
Compare
...sts/org.eclipse.core.tests.runtime/src/org/eclipse/core/tests/runtime/jobs/JobGroupTest.java
Outdated
Show resolved
Hide resolved
...sts/org.eclipse.core.tests.runtime/src/org/eclipse/core/tests/runtime/jobs/JobGroupTest.java
Outdated
Show resolved
Hide resolved
...sts/org.eclipse.core.tests.runtime/src/org/eclipse/core/tests/runtime/jobs/JobGroupTest.java
Show resolved
Hide resolved
e4b7455
to
97a12cf
Compare
97a12cf
to
a6323c1
Compare
...sts/org.eclipse.core.tests.runtime/src/org/eclipse/core/tests/runtime/jobs/JobGroupTest.java
Show resolved
Hide resolved
...sts/org.eclipse.core.tests.runtime/src/org/eclipse/core/tests/runtime/jobs/JobGroupTest.java
Outdated
Show resolved
Hide resolved
95acc32
to
e0b0d0f
Compare
Add the test method org.eclipse.core.tests.runtime.jobs.JobGroupTest.testShouldCancel_5(). See discussion: eclipse-platform#654
e0b0d0f
to
4aef675
Compare
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.
The test seems to be sound now. Hope that we did not drop something important during all the iterations 😉
We can merge after the freeze period.
Add the test method
org.eclipse.core.tests.runtime.jobs.JobGroupTest.testShouldCancel_5()
. This test proves that the cancelation of "sibling" jobs in aJobGroup
should be done via the cancelation policy of the group and not via the monitor.This PR provides doesn't solve any issue, it merely provides context to this discussion: #654 (see comment)