S.D.Process: Add support for passing dwCreationFlags OR Add cross-plat support for each individual flag

[jozkee]

Opening up a discussion to get input on an holistic approach to adding signal support for processes.

Sending a signal to a process is desired when you want to give it a chance to gracefully terminate. In Unix you use kill(pid, signal). On Windows, you use GenerateConsoleCtrlEvent(dwCtrlEvent, dwProcessGroupId), unlike Unix, there's no API to send a signal to a single process, it requires gymnastics to send a signal to one child process without affecting the root process:

• Process must be created with CREATE_NEW_PROCESS_GROUP to isolate it from the parent's group.
• By default, child processes have CTRL+C disabled, so the app must be able to handle Ctrl+Break or you have to create an intermediary app where you explicitly re-enable ctrl+c signals.

Therefore, It feels necessary to add CREATE_NEW_PROCESS_GROUP support as part of this feature, to which I think we have two options:

1. [API Proposal]: ProcessStartInfo.CreationFlags (for Windows only) #71515: opens the floodgates; having Windows-specific APIs is not great but in this case is safer and cheaper than the next option.

2. Add CreateNewProcessGroup to ProcessStartInfo #44944: individual support for creating a new process group, this has the pro (and the con) of not being os-specific, it forces us to think in a way to implement this in Unix, it has the (IMO low) risk of conflicting with future APIs for handling process groups in Unix. I believe, even if more PG support APIs were added, this would be harmless as this would just make that the new process becomes process group leader, but it also feels this is Windows design leaking into Unix.

With that said, I'm looking to gather feedback on which approach we should choose.

Another API that depends on this discussion is #94127.

Is worth mentioning:

• both proposals, CreateNewProcessGroup and CreateSuspended use CreateNoWindow as prior-art, presumably because it also translates to a creation flag. CreateNoWindow is ignored in non-Windows.
• There's plenty of other APIs in Process that are Windows-specific, e.g: Process.CloseMainWindow()

cc @alexrp @fbrosseau @DaZombieKiller @jkotas @dotnet/area-system-diagnostics-process @mladedav @eiriktsarpalis @Tyrrrz @sebastienros @tmds @stephentoub @jeffhandley @dotnet/fxdc @dotnet/linux-team

[jkotas]

[API Proposal]: ProcessStartInfo.CreationFlags (for Windows only) #71515

I think it is fine to add the few Windows-specific creation flag properties that we have scenarios for. These properties would be marked with [SupportedOSPlatform("windows")] and throw PNSE exception on Windows. As you have mentioned, there are number of other similar existing properties like that on ProcessInfo, so this won't be breaking new ground.

I would not try to boil the ocean here. It is a non-goal to introduce properties for all Windows-specific creation flags and options.

Similarly, it is a non-goal to introduce trivial managed wrappers for all niche Windows-specific APIs that somebody may want to invoke on a process, like GenerateConsoleCtrlEvent. The recommendation would be PInvoke those APIs instead.

individual support for creating a new process group, this has the pro (and the con) of not being os-specific, it forces us to think in a way to implement this in Unix,

I do not think a managed process group abstraction would work well. Process groups on Windows and Unix are very different concepts. Here is AI generated summary of the differences: https://chatgpt.com/share/685a2387-41c4-8012-8b82-9035c2c85aaf

Yet another alternative: Create APIs to enable wrapping System.Diagnostic.Process around a process started in a custom way. There is endless number of options to configure process creation on Windows. We do not want to be in the business of creating managed wrappers for every single one of them. Our typical pattern in situations like this is to allow users to P/Invoke the OS APIs to create the OS object and then wrap the built-in managed type around it. FileStream is a good example: You can create file handle in any way you want and then wrap a FileStream around it and use all APIs that use FileStream with it. This patten is not possible with Process today. We can introduce APIs to change that.

[Tyrrrz]

As I already mentioned in this comment, if the only ultimate goal is to support sending signals, then CREATE_NEW_PROCESS_GROUP behavior can be implicit.

Suggested API:

// This instructs the process to be created with `CREATE_NEW_PROCESS_GROUP` on Windows.
// Does nothing on Unix.
processStartInfo.AllowSignals = true;

// ...

// This throws if `processStartInfo.AllowSignals` was not set to `true` earlier.
process.SendSignal(...);

[jozkee]

// Does nothing on Unix.
processStartInfo.AllowSignals = true;

It would be misleading on non-Windows, one could think that AllowSignals = false would block signals from reaching the process.

// This throws if processStartInfo.AllowSignals was not set to true earlier.
process.SendSignal(...);

I support @jkotas on considering GenerateConsoleCtrlEvent and kill trivial pinvokes. We should not add managed wrappers for them.

[jozkee]

I believe we should go with #44944 and annotate CreateNewProcessGroup with [SupportedOSPlatform("windows")].

[DaZombieKiller]

It's been a while since I had to deal with Process issues, but from what I remember my pain points were:

• No way to create a Process from a SafeProcessHandle
• Cannot retrieve any useful information from a SafeProcessHandle (especially on non-Windows)

Those two issues made it very difficult to expose a public API that utilized Process and SafeProcessHandle that could use P/Invoke for OS functionality under the hood. If those two are implemented, I don't think you strictly need any additional APIs implemented in the BCL to achieve what you need. They would just be additional conveniences.