Description Natasha D'Silva 2010-10-14 18:16:31 EDT

Build Identifier: 3.6

From the comment in JobManager.java:
 * There are various locks used and held throughout the JobManager
 * implementation. When multiple locks interact, circular hold and waits must
 * never happen, or a deadlock will occur. To prevent deadlocks, this is the
 * order that locks must be acquired.
 * 
 * WorkerPool -> JobManager.implicitJobs -> JobManager.lock -> 
 * InternalJob.jobStateLock

But JobManager#resume:
	/*(non-Javadoc)
	 * @see org.eclipse.core.runtime.jobs.IJobManager#resume()
	 */
	public final void resume() {
		synchronized (lock) {
			suspended = false;
			//poke the job pool
			pool.jobQueued();
		}
	}

jobQueued is a synchronized method in WorkerPool, so I'm not sure if there is a valid reason for invoking this method within the synchronized block or if this is just an oversight. I don't know much at all about the job manager but this seemed like a potential problem

Reproducible: Always