Description Randall Theobald 2008-04-14 16:42:48 EDT

I am a performance analyst of an adopting product. Part of our next stage of performance improvements involves some multi-threading. During my prototyping I have run into a limitation in the Jobs API.

I want to be able to break a Job up into multiple child Jobs and allow them to execute concurrently. However, each child Job will need access to an unknown set of resources in the workspace to do its work. All the resources are contained by the rule held by the parent Job, however, I need to implement my own rule contention among the child Jobs. While I can use the ISchedulingRule.contains(..) method in a custom rule on my child Jobs to listen for when a Job needs a rule, there is no way to know that the Job is done with a rule (until it is completely finished).

I propose that some additions be made to the Jobs API to allow registration of something like an 'IJobRuleChangeListener' that has two methods: 

   beginningRule(ISchedulingRule rule);
   endingRule(ISchedulingRule rule);

This would allow custom rule contention.

As a side note, this is necessary since the Jobs API doesn't already include the concept of parent and child jobs, in terms of scheduling rules. I understand this as it would probably just add typically unused complexity. However, this all comes about because we have particularly heavy builders and we need to implement some parallel processing during the build cycle. Unfortunately, an Eclipse build is painfully single-threaded... There may be more demand for this sort of thing as the number of CPUs/cores increases in a typical desktop.