Skip to content

Implement wait & cooperative exit on signals (Ctrl-C) #1263

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

BugenZhao
Copy link

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 (or SIGINT) is sent to the process group of cargo-make...

  • If CTRL_C_HANDLING is left off, we get cargo-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.

    • In interactive shell, we may see logs from child process leaking below the next shell prompt;
    • for non-interactive cases (for example, a docker container running a shell script), there won't be chance for child process to finish its clean-up process (if any), because the container is considered to have finished.
  • If CTRL_C_HANDLING is on, we still have problems running interactive commands in cargo 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 like SIGINT and SIGQUIT similarly to a shell. After some investigation, I believe it would be optimal for it to follow the behavior of bash. 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?

Signed-off-by: Bugen Zhao <i@bugenzhao.com>
Signed-off-by: Bugen Zhao <i@bugenzhao.com>
@sagiegurari
Copy link
Owner

thanks. 8 know there are many issues in this area. will review it soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants