|[eclipse.org-architecture-council] [Bug 246840] New: [discussion] How to use Jobs and ISchedulingRule properly?|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=246840 Product/Component: Platform / Runtime Summary: [discussion] How to use Jobs and ISchedulingRule properly? Product: Platform Version: 3.4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: Runtime AssignedTo: platform-runtime-inbox@xxxxxxxxxxx ReportedBy: martin.oberhuber@xxxxxxxxxxxxx CC: john_arthorne@xxxxxxxxxx, markus.schorn@xxxxxxxxxxxxx, eclipse.org-architecture-council@xxxxxxxxxxx Depends on: 246839 Javadocs for ISchedulingRule.isConflicting() vs. ISchedulingRule.contains() are there, but missing on the point how it is supposed to be used. How to write a contains() rule properly? How to use it with RuleFactory and MultiRule? This question stems from bug 240888, which tries to save Project Preferences properly in a Job. How to declare a SchedulingRule that allows this run concurrently with other projects? We need to run a job with a project-rule. Additionally in the job some project-preferences will be flushed. The flushing will potentially lock some resources, outside of the project!!. - Problem 1: SchedulingRules need to be created in advance, and cannot be changed/added/extended later on. So, the creator of the Job has to know in advance, that the flushing of the preferences will lock resources. I need to look at its implementation to figure out the maximum of resources that will be locked. This is against information hiding (and may break in the future, when implementation is changed). - Problem 2: The rules are determined via IWorkspace.getRuleFactory(). It turns out that the rules I obtain from there can differ from call to call. This makes the situation worse in that I can run into an IllegalArgumentException, even if I obtained the rules for the job in the same way as it is done in the methods I am using inside of the job. How to use it properly? Bug 240888 is currently marked fixed, it was solved by taking a Workspace rule. But is this the best we can do? The general problem seems to be that the creator of the Job needs to know in advance what locks are required, even if his job calls out to other (unknown) items. * Is this restriction really required in all cases? Or could some "specially marked" SchedulingRules allow extension later on in the Job, for rules that are safe because they cannot be taken "in the wrong order"? * Should it be part of API Docs what SchedulingRules some API Call requires? This likely wouldn't work with synchronous callbacks. * Is there some different usage pattern to avoid the problem? How to use RuleFactory and MultiRule properly? There also seem to be some semantic problems with ISchedulingRule#contains(), which I filed separately (see bug 246839). -- Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Back to the top