Summary: | If a file is touched and then auto-build is turned on, auto-build job is marked as a system job | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Mike Morearty <mike> | ||||||
Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> | ||||||
Status: | NEW --- | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | ||||||||
Version: | 3.3 | ||||||||
Target Milestone: | --- | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Mike Morearty
2007-06-06 03:46:02 EDT
arg, got submitted too soon... 8 continued: invoke Sample Menu > Sample Action. As you'll see, the build starts (the console is waiting for your input), but there is no "Building workspace" indication. If you go to the Progress view and turn on the display of system viesws, you will see the build job there. Created attachment 70284 [details]
Plugin to reproduce the problem; includes source
Created attachment 70286 [details]
Source of the plugin
If you prefer to build the plugin yourself, use Eclipse's New Plug-In Project wizard, pick the "Hello World" sample, and then replace the generated SampleAction.java file with this one.
Oh yeah, and if you add Thread.sleep(1000) after the code that touches foo.txt but before the code that turns auto-build back on, then the problem goes away, further proving that it's a race condition. I believe you that there is a race condition, but I'm not sure we can do much about it. When autobuild is turned off, we still need to run the autobuild job to invoke listeners. Immediately before the autobuild job is scheduled, we check if autobuild is turned on, and set the job as a system job accordingly (AutoBuildJob.build). If autobuild is turned on after the job has been scheduled, it's too late to change it (system state must be set before a job is scheduled). The only option would be to detect the change from within the running job, and cancel and reschedule the job, which is a bit drastic and can have negative consequences. I was thinking more along the lines of rearranging things a bit so that the AutoBuildJob no longer needs to switch back and forth between system job vs. non-system job. For example, maybe the job could be split into two jobs. The main job would always get invoked as a system job. Then, in AutoBuildJob.doBuild(), wrap the actual build invocation in a non-system job -- change this: IStatus result = Status.OK_STATUS; if (shouldBuild()) result = workspace.getBuildManager().build(trigger, Policy.subMonitorFor(monitor, Policy.opWork)); To something like this: final IStatus[] result = new IStatus[1] { Status.OK_STATUS }; if (shouldBuild()) { // 'job' is a non-system job Job job = new Job("building") { public IStatus run(IProgressMonitor monitor) { result[0] = workspace.getBuildManager().build(trigger, Policy.subMonitorFor(monitor, Policy.opWork)); } }; job.schedule(); job.join(); } By the way, the real-life scenario in which I into this was as follows: We have a new-project wizard that turns off autobuild, creates the project, and then turns autobuild back on. Because it turns autobuild back on immediately after creating the project, I was hitting this race condition, so the result for the end user was that for the entire time the build was happening, the user saw no indication that the build was taking place; and, if the user tried to do anything that touched the project, such as save a file, it would block with no explanation of why it was blocking -- the dialog would come up indicating that the save was waiting for something else to finish, but the "Building" job was not in that dialog. By the way, in the new-project wizard that I just described, I worked around this bug by sleeping for a short while -- 100ms if I remember correctly -- immediately after creating the project and before turning on auto-build. That's usually long enough to give the build job time to get started. Your best bet is to actually wrap the project creation and the re-enabling of autobuild in a single workspace runnable (IWorkspace.run). That will more reliably prevent autobuild from being scheduled in between. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. |