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.
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.
On Mon, Jul 21, 2014 at 1:15 AM, Adam Murdoch <[hidden email]> wrote:
Do you want to handle this in shutdown hook or using some custom signal handler? BTW: this cancel affects only one daemon process
Do you mean when the connection is not correctly closed?
It is nice to have to add this to tooling API at the moment IMO.
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).
Yes, so it is really a bit different from stop where the daemon exits.
Sounds reasonable. It's not there yet but I think I can do it soon.
I will have questions about this too later. :-)
On 22 Jul 2014, at 6:02 am, Radim Kubacki <[hidden email]> wrote:
This is already there. The client simply drops the connection, which ends up in a call to requestForcefulStop() in the daemon. There’s no cancelation protocol between the client and daemon. This is good enough for now.
requestForcefulStop() would turn into something to request that the current build be cleaned up.
Let’s leave that for now.
The ctrl-c kill the client, which the daemon sees as a disconnection. The client wouldn't hang around for the cancelation to complete (but `gradle —stop` should). We could potentially wait a short time when the client disappears (#2 and #3) and a longer time when we can give feedback to the client (#1 and #4).
|Free forum by Nabble||Edit this page|