[API Proposal]: Add API to gracefully terminate process

[tmat]

Background and motivation

dotnet-watch needs to be able to terminate process gracefully, i.e. give it a chance to clean up resources.

On Windows this API would call GenerateConsoleCtrlEvent, on Unix it would send SIGTERM signal.
Currently this requires reimplementing both process creation and termination using P/Invokes.

API Proposal

Multiple options. One option is to add parameter to Process.Kill that indicates whether we want forced kill or "soft" termination (Ctrl+C/SIGTERM).

Process.Kill(bool entireProcessTree, bool forced = true);

ProcessStartInfo might need a bool property, say EnableConsoleControlEvents that allows Kill to send Ctrl+C.

API Usage

var process = new Process
{
    StartInfo =
    {
        EnableConsoleControlEvents = true
        // file name, arguments, output redirection, etc.
    }
};

process.Start();

process.Kill(entireProcessTree: false, forced: false);

process.WaitForExit();

Alternative Designs

Related: #71515

Risks

No response

[Symbai]

Process.Kill that indicates whether we want forced kill or "soft" termination

The word kill conflicts with soft. Especially when doing it gracefully the other process still has the option to say "nope". Since we already have Process.CloseMainWindow which gracefully closes a process if it has a window, for me it makes more sense to introduce a new method, something like Process.CloseConsole etc. Otherwise it gets confusing especially for beginners which method they would have to use.

[karakasa]

just fyi GenerateConsoleCtrlEvent cannot send events to arbitrary processes (unless within the same console or created with a certain flag).

[rjgotten]

Process.Kill that indicates whether we want forced kill or "soft" termination

The word kill conflicts with soft. Especially when doing it gracefully the other process still has the option to say "nope". Since we already have Process.CloseMainWindow which gracefully closes a process if it has a window, for me it makes more sense to introduce a new method, something like Process.CloseConsole etc. Otherwise it gets confusing especially for beginners which method they would have to use.

^ This, indeed.
Instead- what seems to be needed is something like a

public class Process
{
  async Task<bool> RequestTerminateAsync(CancellationToken cancellationtoken);

  // ...
}

It should be awaitable because shutting down gracefully may take a bit.
Moreover, there may be time-window affordances at play for a graceful shutdown vis-a-vis a forceful one. And those might even be OS-dependent.

Which means only afterwards, you can know whether the process was actually terminated or not.
(And you might have a need to continue to issue a process.Kill if it decided to 'not come quietly.')

[fbrosseau]

just fyi GenerateConsoleCtrlEvent cannot send events to arbitrary processes (unless within the same console or created with a certain flag).

The answer has more corner cases as well - if the process is attached to a modern pseudoconsole to which you have a handle to stdin, you can write 0x3 to stdin too. This is the most reliable way to implement ctrl-c today. But the underlying problem remains the same - you need specific knowledge of the child to implement this properly on Windows - there is no generic solution.

Because these scenarios require deep control of both the child's code, as well as the code actually creating the child process, usually this is best accomplished by just pinvoking CreateProcess. This opens the door to other improvements that aren't really possible to implement generically (because they're breaking changes), such as providing a duplex async pipe as stdout/stdin instead of the current model where sync-only anonymous pipes are used by dotnet.

Even if it's dotnet creating the process, it can't really know that the child it is creating is itself also dotnet.

This API proposal sounds super convenient for consumers, but as with most process-related advanced features, it's hard to implement as a framework.

[tmat]

The answer has more corner cases as well - if the process is attached to a modern pseudoconsole to which you have a handle to stdin, you can write 0x3 to stdin too. This is the most reliable way to implement ctrl-c today. But the underlying problem remains the same - you need specific knowledge of the child to implement this properly on Windows - there is no generic solution.

Seems like the API can support both ways of sending Ctrl+C and it can either detect what the state process is or it can take a flag so that the caller can choose.

Reimplementing process launching via P/Invokes is not a good option. It shifts the burden of testing all the corner cases and quirks of all the supported OSes to the implementation.

[jeffhandley]

This API proposal sounds super convenient for consumers, but as with most process-related advanced features, it's hard to implement as a framework.

I agree with that assessment, and I think this would need a substantial time investment that our team won't be able to make. I'm happy to leave this open though if others want to prototype it out. I'll mark it as help wanted [up-for-grabs] Good issue for external contributors .