Community
Participate
Working Groups
Build Identifier: 20110613-1736 sometimes eclipse takes a long time (many minutes) to cancel a build. (if at all) which this build cancel request is processing, all save operations are blocked. this leads to lost code when the IDE crashes, or is killed by the user (because the build refuses to cancel). nothing should block the save operation except the inability to acquire a write lock on the file being saved. it's easier to mark a build as invalid (and rebuild) than to rewrite lost code. alternatively: the user could be be prompted "saving now will invalidate your build - continue?" Reproducible: Always Steps to Reproduce: 1. hit ctrl-b (to start a build_ 2. cancel the build 3. attempt to save a file
Created attachment 218729 [details] screenshot of issue
which => while
(In reply to comment #0) > sometimes eclipse takes a long time (many minutes) to cancel a build. (if at > all) While I know that this can be annoying, it would be important to know which builders are involved when a build becomes unresponsive. I'd be surprised if one builder alone (e.g., the javabuilder) gets stuck, I'd expect this to be a contention between several builders, or perhaps contention with some external process, even. > which this build cancel request is processing, all save operations are > blocked. this leads to lost code when the IDE crashes, or is killed by the > user (because the build refuses to cancel). > > nothing should block the save operation except the inability to acquire a write > lock on the file being saved. It may not be a native file lock but likely a scheduling rule is blocking the save operation. At that time forcing a write (which the current API won't allow) could cause any kind of corruption, I'm afraid. > it's easier to mark a build as invalid (and > rebuild) than to rewrite lost code. alternatively: the user could be be > prompted "saving now will invalidate your build - continue?" Ignoring scheduling rules is not a solution. The canonical solution would be to identify the rogue builder(s) and ensure they react to cancel. Alternatively, I could think of an emergency region, where files could be saved even if scheduling rules prevent writing to their original location. Any fundamental changes to resource handling would have to be addressed by Platform/Resources, maybe they have more ideas. In JDT land we can only try to identify contention involving the Java builder and try to resolve that.
*** This bug has been marked as a duplicate of bug 329657 ***
