The test case
org.eclipse.core.tests.runtime.jobs.JobEventTest.testDeadlockRecovery
can randomly fail as it relies on specific operations terminating within
specific amounts of time, such as the abortion of a schedule operation
due to a deadlock providing stack traces fast enough. Whether this
succeeds depends on the performance of the executing infrastructure.
The change simplifies the test case and assigns proper timeout values:
All synchronizing calls between the different threads/jobs now rely on a
barrier whose timeout is implemented in a generic way, so that it may
only fail if there is really no further progress. The timeout for job
listeners (indicating a deadlock) is kept and a significantly higher
timeout for the join operation is added, as it is only relevant in case
of a regression and can thus have a high value to avoid the potential of
random failures on slow hardware.