On 10 Jul 2014, at 2:30 am, Radim Kubacki <radim.kuba...@gradleware.com> wrote:
> Hi, > > here are some comments to > https://github.com/gradle/gradle/blob/master/design-docs/tooling-api-cancellation.md > I think Adam will have comments when he gets back. Since he is not there I > will share it this way. > > Story: Daemon waits short period of time for cancelled operation to complete > > I think we need to distinguish between 'request to stop the daemon' and > 'cancel the build' which is not the case in current spec. > > - 'request to stop the daemon' is now implemented in > DaemonStateControl.requestForcefulStop(). This is called from client side > using DaemonClient.stop() where Stop command is sent to server that processes > it in its StopHandler. It can break an existing connection for the command > that can be running at the moment and will cause the daemon server to exit. > This works well for CLI call 'gradle --stop' and it is good enough as the > basic implementation of cancellation > > - 'cancel the build': we don't want to stop the server if it is possible to > stop the execution in some soft way (and within reasonable time). If this > fails we can either ignore the cancel event or stop the daemon as described > above. There are 4 use cases we want to deal with here: 1. Tooling API client cancels a build that it started. 2. User cancels a command-line build by killing the client using ctrl-c 3. The daemon loses the connection to the client. 4. User requests that all daemons be stopped. There will probably be an equivalent in the tooling api at some point. At this stage we can’t distinguish between #2 and #3, but it’s certainly possible. The goal for #1 and #2 is to have the daemon clean up the build within some reasonable period of time. Same for #3. The goal for #4 is to have the daemon clean up the build within some reasonable period of time, and then exit. There should not be any real difference between stop and cancel, except that stop also exits the process at the end. Implementation-wise, the first cut of “clean up the build” is simply to exit the process. The second step (the story in question) would be to change the implementation to: 1. wait for a short period of time for the current operation to complete 2. if the operation does not complete in this time, request that the process exit. stop becomes: 1. attempt cancelation and wait until there is a result. 2. request that the process exit. The third step would be to get some of the workers involved in cancelation, starting with the task execution graph. When cancelation is requested, the task graph will no longer start executing tasks, but will continue to execute whatever it is currently executing. Later steps can do similar things for configuration actions and tooling builders. -- Adam Murdoch Gradle Co-founder http://www.gradle.org CTO Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
