Implement wait & cooperative exit on signals (Ctrl-C) #1263
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi, and thanks for your great project.
I noticed there were many discussions about ctrl-c before (#374), and an option
CTRL_C_HANDLING
was introduced to offer an alternative behavior which could be suitable for some use cases.To be honest, whether or not this feature is enabled, the current behavior of
cargo-make
is not ideal. When a Ctrl-C (orSIGINT
) is sent to the process group ofcargo-make
...If
CTRL_C_HANDLING
is left off, we getcargo-make
being terminated immediately, while the currently running command become an orphan and may continue running in the background. Such exit may not be considered "clean" in any circumstances.If
CTRL_C_HANDLING
is on, we still have problems running interactive commands incargo make
, as described in ctrl+c exits long-running command (REPL) unexpectedly #954. Ctrl-C can be a normal input for the subcommand, but the current implementation always kill it on the second press, which is confusing.Instead and from my own perspective,
cargo-make
as a task runner should handle signals likeSIGINT
andSIGQUIT
similarly to a shell. After some investigation, I believe it would be optimal for it to follow the behavior ofbash
. This approach, known as Wait & Cooperative Exit (WCE), is thoroughly explained in this post: https://www.cons.org/cracauer/sigint.html.I drafted this PR on those ideas as well. But there might still be some remaining issues to be addressed:
What should be the ideal relationship between WCE and the previously introduced
CTRL_C_HANDLING
? Should we retain it, replace it, or directly stabilize WCE if it seems satisfactory to you?Shall we make this
unix
only, as I assume Windows may have completely different convention or implementation?