Community
Participate
Working Groups
Created attachment 102774 [details] Initial Patch Steps To Reproduce: 0. Choose a large project 1. Make a change to a file with lots of dependents 2. Press Ctrl+S to launch auto build 3. Quickly make another change to the file and press Ctrl+S to save Notice that a blocking dialog appears. The desired result is that no blocking dialog appears, and that the save progresses unhindered. For a long time we've desired to be able to save and build at the same time, since, in large projects, it is more than inconvenient that these operations block each other. Douglas and I have attempted to provide a patch indicating a suggested fix. The patch is not complete, but we offer it here for discussion. The idea is to run builds without the workspace lock, and then to launch a write job from within the build. This write job will acquire a lock, write the new contents of the file and release the lock. Current issues: + The write job is asynchronous and so as the build progresses, it could potentially be reading stale information. Perhaps this can be fixed with a call to join. + The write job acquires the complete workspace lock. Is this really necessary? + We have taken a shortcut in that Rules.buildRule() has been modified. This strikes us as a potential API violation. Perhaps the correction solution is to create a buildRule2() function. Builders that can safely run in this environment can then update to use buildRule2() instead. Another alternative to that is to provide for a "Preference" that configures this new behaviour. The patch likely has several problems, as the code is complex. But if you provide input, we would be happy to continue working on this.
Adding Kent to CC for comment on the Java builder, since this patch is mostly on the java builder. My guess is that it would be very difficult to implement a builder that would work correctly without at least locking the project being built. This patch may appear to work but I'm sure there are cases where it will produce incorrect results because it has no consistent point of reference to build against. For example it may resolve a reference to a method and create byte codes based on that reference, and then if the method was deleted concurrently the binding could be incorrect, resulting in linkage errors at runtime. To get a correct result, it would need to throw away its progress so far and restart the build after any concurrent change.
I don't see why there would be a need to cancel an ongoing build to achieve correctness: any change to, say in your example, a method while a build is running will trigger another build. That second build will be "locked" (i.e. not eligible to run, for it can't acquire the lock) until the first build finishes. But, when that does, it will proceed, and it will operate on the correct deltas, and recompile the transitive dependencies. What am I missing?
ping
Created attachment 115645 [details] Patch (Version #2, HEAD as of 2008-10-20 4:15 p.m. PDT) Merged to head around 4:15 p.m. (PDT) and rebuilt the patch.
Comment on attachment 115645 [details] Patch (Version #2, HEAD as of 2008-10-20 4:15 p.m. PDT) Wrong bug
I've looked only at core.resources part of the patch. BuildSchedulingRule doesn't contain the workspace rule which is needed to send PRE and POST_BUILD events. See AutoBuildJob#doBuild. If you register a listener for either of those events and you try to modify workspace inside, you will get "Attempted to beginRule: [some workspace rule], does not match outer scope rule: BuildSchedulingRule" surely.
Similar issue is bug 198591. See bug 198591, comment 13.
Would it be possible to grab the workspace lock for the PRE_BUILD, then drop. Grab the build lock for the build, then drop. And then grab the workspace lock for the POST_BUILD again, and then drop?
Re comment #8: yes, this is what the latest patch in bug 198591 does. I talked about your general strategy with the lead developer of the incremental Java builder the other day. His belief was that this will probably work most of the time, but could easily be made to break due to particular assumptions made by the Java builder. Notably, the Java builder currently assumes that the delta it receives accurately describes the state of its prerequisite projects at the time that builder started. For example if the delta indicates that resource "X" was ADDED or CHANGED, the builder will assume that X currently exists (otherwise it would have received a REMOVED delta). The Java builder also maintains a binary representation of a project's "built state", and assumes that the "built state" of prerequisite projects accurately describes the current state of that project's class files during a workspace build. If this assumption is violated it could easily result in exceptions in the builder logic. All of this is not to say that the strategy cannot work - just that it breaks assumptions that builders can safely make today. The approach Szymon is taking in bug 198591 is to introduce the ability for builders to specify their own scheduling rule. If a builder decides it can live in a fully dynamically changing world it can use a scheduling rule of "null", and this would then result in the fully non-blocking behaviour you're looking for.
My impression is that this is a duplicate of bug 198591.
*** This bug has been marked as a duplicate of bug 198591 ***
Reopening, since bug 198591 has been marked as fixed and yet it is still not possible to save a java editor while a build is going on.
(In reply to Stefan Xenos from comment #12) > Reopening, since bug 198591 has been marked as fixed and yet it is still not > possible to save a java editor while a build is going on. This bug and bug 198591 are about making it possible to use a custom build scheduling rule and this was fixed. Since that time there were many different changes improving the save editor experience while Java build is running (including recent fix for bug 454698/bug 60964), so if you are still seeing some delays when saving, please open a new bug and provide steps how to reproduce your problem. *** This bug has been marked as a duplicate of bug 198591 ***
> so if you are still seeing some delays when saving, please open a new > bug and provide steps how to reproduce your problem. Using the steps from comment 0 I can still reproduce this problem: Steps To Reproduce: 0. Choose a large project 1. Make a change to a file with lots of dependents 2. Press Ctrl+S to launch auto build 3. Quickly make another change to the file and press Ctrl+S to save > This bug and bug 198591 are about making it possible to use a custom > build scheduling rule and this was fixed. Bug 198591 was about the ability to add custom scheduling rules. This bug is about making the steps to reproduce in comment 0 work correctly and they do not. My reasoning is as follows: 1. The content of comment 0 and any subsequent clarifications from the original poster describes what the bug is about. 2. The steps to reproduce in comment 0 still reproduce the problem. 3. There was no follow-up correction from the original poster indicating that he indended anything other than the steps from comment 0. If you believe this to be fixed, please describe which part of my reasoning you disagree with. Do you disagree with the factual claim that the steps to reproduce still demonstrate the problem? Do you disagree with the general principle that the description provided by the original poster is what a bug is about? Or did you see a comment from the original poster indicating that the original steps to reproduce were incorrect or incomplete?
Note that the bug description mentions Java builds, so it's a reasonable assumption that step 1 in comment 0 is meant to refer to a .java file.
Let me rephrase. I disagree with this claim: > This bug and bug 198591 are about making it possible to use a custom > build scheduling rule Since I see no comment in this bug from "Z" Zorzella indicating that he was either interested in the ability to use custom build scheduling rules or that he was no longer interested in the steps to reproduce posted in comment 0.
Hey, Zorzella here. FWIW, the problem still exists. It's less painful than it used to be, but the java build still blocks saves. External builds also block saves. My dream would be that Eclipse would never stop me from saving my files, and addressing it for the java builder that was the original intent of this bug (and patch). FWIW as well, I'll attach here a few screenshots of the progress bar that pops up if you try to save when Eclipse is compiling (taken with Eclipse 4.5). Two of the screenshots are saves that are blocked on the java builder, and the other three are blocked on external builders (as per their names).
Created attachment 255035 [details] BlockedOnJavaBuild0.png
Created attachment 255036 [details] BlockedOnJavaBuild1.png
Created attachment 255037 [details] BlockedOnExternalBuild0.png
Created attachment 255038 [details] BlockedOnExternalBuild1.png
Created attachment 255039 [details] BlockedOnExternalBuild2.png
(In reply to Stefan Xenos from comment #16) > Let me rephrase. I disagree with this claim: > > > This bug and bug 198591 are about making it possible to use a custom > > build scheduling rule The whole discussion in this bug including the patch proposed by "Z" Zorzella in comment 0 concentrate around changing build rules. I didn't say the steps in comment 0 are not valid or they do not allow to reproduce a problem only that the approach which was discussed here is already implemented. > Since I see no comment in this bug from "Z" Zorzella indicating that he was > either interested in the ability to use custom build scheduling rules This was mentioned in comment 0: >> + We have taken a shortcut in that Rules.buildRule() has been modified. and it confirms "Z" Zorzella and follow up comments discussed making build rule more flexible, regardless of how it related to original steps to reproduce the problem. Making build rule more flexible was fixed in bug 198591. See comment 9 which clarifies the relation. > or that he was no longer interested in the steps to reproduce posted in > comment 0. I fully agree, but reopening the bug after many years where almost all comments of the bug refer to something that is already implemented does not help in narrowing down the problem. The problem that Java builder may block user action is still alive and it is tracked in bug 329657, so if you really want to monitor the "Java builder may block user action" problem, then please subscribe to bug 329657 because it contains more relevant discussion than this bug. I'm marking this bug as duplicate of 198591 again because this is the one which contains the fix for making build rules more flexible which was discussed here. *** This bug has been marked as a duplicate of bug 198591 ***
I agree that the discussion went a bit into a different direction, but as said in this bug, the fix for bug 198591 does not solve the problem for the Java builder and other builders, as they cannot easily use a smaller lock. Let's mark this bug as duplicate of bug 329657, which captures the originally reported problem and has some interesting discussions. *** This bug has been marked as a duplicate of bug 329657 ***
