Community
Participate
Working Groups
Created attachment 287981 [details] Screenshot cancel dialog Autobuilds blocks any user operation requiring a workspace rule, and that can be a long time on big projects. In that case the user has the possibility to manually cancel either the user operation or the autobuild. (or gets a UI freeze if the user operation does not use the approriate API to show that dialog!) It would be better if the autobuild is automatically canceled in that case and resumed after the user operation. We already have custom operations which use that pattern for a long time, but there is no public API for that. I request either of these: a) Add a public API (basicly simply like core.internal.events.BuildManager.shutdown()) b) Change the existing API to cancel the current Autobuild when Autobuild is changed to disabled. (Currently autobuild is restarted when autobuild is enabled but not stopped when disabled) Further i ask to use that feature for either c) certain existing jobs that we know that should have precedence over autobuild (like saving a file). d) generically use it for all operations that request a conflicting rule. Since the autobuild should restart after the user operation i don't see a problem. i would prefer a) and d)
i just found there already exist such a concept with BuildManager.interrupt() called from Workspace.prepareOperation(ISchedulingRule, IProgressMonitor). I need to investigate why that does not work as intended in some use-cases.
Two problems: 1. minor race condition: autobuild will retry to resume after interrupt. If it is faster in acquiring the ISchdeulingRule lock again than the User action, then the User actions interrupt() event is lost (bug 170356 tried to fix that but just relies on scheduling delay). 2. Many useractions do not try to interrupt (by using Workspace.prepareOperation) but call JobManager.beginRule() directly. In special all actions that use org.eclipse.ui.progress.IProgressService.runInUI() - which shows that waiting dialog. the challenge: org.eclipse.platform.ui does not know about org.eclipse.platform.resources (well except org.eclipse.ui.internal.LegacyResourceSupport) there is also a related test: org.eclipse.core.tests.internal.builders.BuilderTest.testInterruptAutobuild() I think it needs to extend Job with a method to request interrupt - which autobuild needs to listen on.
3. even if interrupt() is triggered. literally only AUTO_BUILD is interrupt but not INCREMENTAL_BUILD - even though it was automatically triggered in my case: BuildManager.basicBuildLoop automatically elevates INCREMENTAL_BUILD to INCREMENTAL_BUILD after every iteration - which especially comes into play when xtext requests a second round.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/190559
(In reply to Eclipse Genie from comment #4) > New Gerrit change created: > https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/190559 See bug 10262 comment 40. The changed lines were added to support multiple build cycles. Please check that the proposed change is not breaking *real* cyclic builds (not just those from Xtext builder unhappy with something).
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/190559 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=98d9b5060f2d78823841a6e6638adeeac76f4fdc
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/190715
*** Bug 518665 has been marked as a duplicate of this bug. ***
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/190715 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=6abd3444b8571f7f973f946cdbdd552dab5ba4cf
