On Mon, Jul 21, 2014 at 1:15 AM, Adam Murdoch <adam.murd...@gradleware.com> wrote:
> > 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 > Do you want to handle this in shutdown hook or using some custom signal handler? BTW: this cancel affects only one daemon process > 3. The daemon loses the connection to the client. > Do you mean when the connection is not correctly closed? > 4. User requests that all daemons be stopped. There will probably be an > equivalent in the tooling api at some point. > It is nice to have to add this to tooling API at the moment IMO. > > 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. > What if I do (ctrl-c ctrl-c)? Should we speed up the exit then? If we do this then the reasonable amount of time can be a bit longer. I can imagine this on command line. I am not sure how to model that in toolingApi reasonably (possibly as cancel build / close projectConnection). > > 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. > Yes, so it is really a bit different from stop where the daemon exits. > > stop becomes: > 1. attempt cancelation and wait until there is a result. > 2. request that the process exit. > Sounds reasonable. It's not there yet but I think I can do it soon. > > The third step would be to get some of the workers involved in > cancelation, starting with the task execution graph. When cancellation is > requested, the task graph will no longer start executing tasks, but will > continue to execute whatever it is currently executing. > I will have questions about this too later. :-) > > 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 > > > >
