Description Min Idzelis 2010-05-10 16:31:35 EDT

Build Identifier: 

This is a combination of 3 very closely related bugs, which is why they are being reported together. 

It all stems from the same root cause, and this cause let me to uncover additional bugs that were always present in the system. 

The root cause exists when a Job that has a non-null Rule is running, and a beginRule() is performed with a nested non-null Rule. 

In these circumstances, the active implicit job (ThreadJob) will choose another ThreadJob to unblock. This usually works. However,the problem is that there are 2 ThreadJobs that represent the same real job. 

There are several causes to why there are two ThreadJobs for the same actual real Job. 
1) In resuming from a yield, the startTime of the job is not changed back to T_NONE. This causes the job to be rescheduled() when it is ended. 
2) In starting a nested ThreadJob via beginRule(), the code path that changes state of this ThreadJob is not invoked. When this inner ThreadJob is ended, it is rescheduled. 
3) If schedule() is called on JobManager.currentJob() after beginRule(). 

Additionally, I noticed that yieldRule() does not look for any blocked jobs on any implicit job. This is a flaw with yieldRule() as it was intended that yielding an implicit job should allow blocked jobs to proceed. 

I have regression test cases and a fix ready. Please stay tuned for the forthcoming patches. 

Reproducible: Always