Community
Participate
Working Groups
Sometimes, code will turn off auto-build temporarily, make resources changes, and then turn auto-build back on. For example, the JDT's new project wizard does this. However, due to a race condition in AutoBuildJob, after this happens, the auto-build job that starts is sometimes marked as a system job, and thus does not show up in the UI. The race condition occurs when some code modifies a resource and then, immediately after that, turns auto-build on. I have not seen this happen with the JDT's new project wizard, but I am seeing it in some code I am writing. The below steps reproduce the problem with some dummy code. 1. Make a new "general" (non-java) project called "testproj" (that name is required -- it is hard-coded into my dummy code) 2. Create an empty file in the project called "foo.txt" 3. Add a Builder for the project that will wait for user input (this is so that the builder won't finish quickly), and will run on every auto-build. Project Properties; Builders tab; New...; Program. If you are on Windows, set the Location to C:\windows\system32\cmd.exe, and the arguments to "/c date" (this will prompt you for the date); if on Mac/Unix, set the Location to "/bin/cat" (this will wait for user input). 4. Still in the Builder's properties, go to the Build Options tab, and check the box for "During auto builds" 5. Click OK, and get back to your editor. Test out your builder -- edit foo.txt and save it. This should cause an auto-build. You will get the normal "Building workspace..." message in the lower right corner, and the Console will be waiting for your input. 6. Click in the Console. If on Windows, press Enter to dismiss the date prompt; if on Mac/Unix, press Ctrl-D to send an EOF to /bin/cat. Either way, the console will no longer be waiting, and "Building workspace..." will go away. 7. Now, install into your Eclipse installation the AutoBuildTest plugin that I'll be adding to this bug as an attachment. This is a very simple plugin that adds some code to (a) turn off autobuild, (b) modify testproj/foo.txt, and (c) immediately turn autobuild back on. 8. Okay, everything set? You have your "testproj", with file "foo.txt", and you have installed the plugin, so there is a new menu "Sample Menu"
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.
