Skip to content

Grace handling user requested process termination #4799

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
JanKrivanek opened this issue May 31, 2022 · 1 comment
Open

Grace handling user requested process termination #4799

JanKrivanek opened this issue May 31, 2022 · 1 comment
Labels
area: CLI Related to dotnet new CLI (usually dotnet/TemplateEngine.CLI source code) Priority:3 Work that is nice to have triaged The issue was evaluated by the triage team, placed on correct area, next action defined.
Milestone

Comments

@JanKrivanek
Copy link
Member

Background:

When user requests a processing exit (via Ctrl-C or Ctrl-Break), templating engine does not grace shut any of it's async processing and the process terminates with wxit code 0xC000013A (STATUS_CONTROL_C_EXIT)

Improved expected behavior:

When user requests a processing exit, templating engine safely cancels all of it's processing, exits once done and signals the situation with exit code 130 (https://tldp.org/LDP/abs/html/exitcodes.html)

How to achieve this:

We should resort from trying to intercept the singla ourselves (with SetConsoleCtrlHandler)
Rather we should use the build in functionality of process termination handling within command-line-api
This will require adding CancelOnProcessTermination to command line builder within sdk
Ideally we should inject this handling for templating subcommand only - in case other subcommands cancellation logic would not be ready (hence leading to uncancellable process). Alternative might be to improve the CancelOnProcessTermination in command line api to allow optional termination processing timeout, after which expiry the process would exit anyway (probably with Environment.Exit(130)) - then we possibly could register the middleware for all dotnet subcommands - those not ready to grace handle cancellation on termination would keep terminating anyways

@JanKrivanek
Copy link
Member Author

In other commands we should use the 'sync to async' wrapper: https://github.com/dotnet/sdk/blob/dbf884654f7559433c732267472fffd75db8e33c/src/Cli/dotnet/commands/ParseResultCommandHandler.cs#L8
It should grab the Cancellation token from context and Wait on the Task with that CancellationToken

@JanKrivanek JanKrivanek self-assigned this Jun 6, 2022
@vlada-shubina vlada-shubina added the triaged The issue was evaluated by the triage team, placed on correct area, next action defined. label Jun 6, 2022
@vlada-shubina vlada-shubina added this to the June 2022 milestone Jun 6, 2022
@vlada-shubina vlada-shubina modified the milestones: June 2022, Backlog Jul 14, 2022
@YuliiaKovalova YuliiaKovalova added Priority:3 Work that is nice to have area: CLI Related to dotnet new CLI (usually dotnet/TemplateEngine.CLI source code) labels May 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: CLI Related to dotnet new CLI (usually dotnet/TemplateEngine.CLI source code) Priority:3 Work that is nice to have triaged The issue was evaluated by the triage team, placed on correct area, next action defined.
Projects
None yet
Development

No branches or pull requests

3 participants