Repository navigation
Add CreateNewProcessGroup to ProcessStartInfo #44944
Description
Background and Motivation
Edited by @jozkee
Creating process groups is necessary to be able to send signals on Windows as they are sent to the whole group, you need to use CREATE_NEW_PROCESS_GROUP creation flag to isolate the signal from the parent process. POSIX systems have the same notion, however in unix-like systems one can use signals directly with processes.
This has been previously discussed in another issue in 2017 but it turned out that this change itself would not help the requesting team so it was dropped at that time. For the record, I am using proposals from that time.
Proposed API
Expose the creation flag via a Windows-only property.
namespace System.Diagnostics
{
public sealed partial class ProcessStartInfo
{
+ [SupportedOSPlatform("windows")]
+ public bool CreateNewProcessGroup { get; set; }
}
}Usage Examples
var startInfo = new ProcessStartInfo
{
FileName = "my-program.exe",
CreateNewProcessGroup = true,
};
var p = new Process.Start(startInfo);
// Do some work...
GenerateConsoleCtrlEvent(0 /* CTRL_C_EVENT */, (uint)process.Id)
[DllImport("kernel32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool GenerateConsoleCtrlEvent(uint dwCtrlEvent, uint dwProcessGroupId);Alternative Designs
-
[API Proposal]:
ProcessStartInfo.CreationFlags(for Windows only) #71515 was considered but I've opted for this proposal instead as we do have concrete scenarios for it. -
[API Proposal]: Add API to gracefully terminate process #109432, diffrent property naming:
EnableConsoleControlEvents. This name makes sense if CREATE_NEW_PROCESS_GROUP has no other reason to be used for, outside of signal isolation, I'm unaware of more scenarios where this is useful but that can change in the future.
Risks
None
Activity
eiriktsarpalis commentedon Nov 20, 2020
If I get this correctly, in order to obtain the same behaviour as
CREATE_NEW_PROCESS_GROUPon Unix we would need to callsetpgid(0, 0);between fork and execve?mladedav commentedon Nov 23, 2020
I believe so. That would put the new process into a new process group with ID identical to that new process' ID.
eiriktsarpalis commentedon Nov 23, 2020
My concern about this proposal is that it seems to only allow a very constrained use case for process groups. What if I wanted to create a process group that includes the current process?
It is probably telling that in the original issue it was determined that ProcessStartInfo is probably not the appropriate API for making this type of configuration. So if we can't provide a general-purpose solution here, perhaps we shouldn't be adding it at all.
mladedav commentedon Nov 23, 2020
As I understand the comment, ProcessStartInfo wasn't appropriate for the advanced usage PaulHigin needed, not for the flag itself. I can't think of a better place for this since this needs to be set before the process is started, but I do not mind it being anywhere else.
The constraints are based on what both Windows and Linux can do - Windows only has a flag
CREATE_NEW_PROCESS_GROUPforCreaetProcess*functions while Linux is able to change the group ID dynamically after fork.If you want the new process to be part of the creating process' group, you simply don't specify the option, it is the default in both OSs.
adamsitnik commentedon Nov 26, 2020
Triage:
We should do research and find out if Windows allows for modifying process group after process creation as Unix does. If it does, we should consider adding APIs for all possibilities:
If it's not possible, the current proposal looks as good as it is.
Tyrrrz commentedon Feb 8, 2021
Note: as @mladedav initially pointed out, the primary goal of this feature is to allow sending signals to the process on Windows.
If
Processsomehow exposed this functionality directly (e.g. with aprocess.SendSignal(...)method), then this switch would not be needed and may become an implementation detail (i.e.Process.Start(...)may still create a new process group, just not expose it to the caller).ItsRevolt commentedon Dec 24, 2023
I am affected by this as well in a very similar way to the above mentioned issue (pulumi/pulumi-dotnet#124)
Wanted to comment on this just to show there is a want for this, as the previous issue was closed due to lack of use by devs.
lennybacon commentedon May 10, 2024
Any updates?
2 remaining items
jilles-sg commentedon Jun 26, 2025
Please note the restriction on modifying the process group of an existing other process using
setpgid: this can only be done if the target process has not calledexecveor a similar function yet. In fact, that form of the call is only intended to allow the parent process to ensure the process group has been set in the absence of other synchronization (such as the pipe .NET uses to obtain the return value fromexecve). The child process should always set its own process group ID (if the parent's process group ID is unsuitable). If the parent process encounters the error condition[EACCES]that the target process has already calledexecve, the process group has already been set, so the parent process needs to ignore the error.Instead, the extra possibilities of
setpgidare for two use cases:Documentation should warn that starting a process in a new process group may have unexpected effects if the process has a controlling terminal. In particular, the child process will not receive signals from key combinations such as Ctrl+C and will be suspended if it tries to read from the terminal (the kernel assuming that the parent process will deal with that).
If the process does not have a controlling terminal, creating new process groups is fine and allows sending signals to whole trees of processes except those that actively change their process group ID.
If Windows provides no way to create multiple child processes and have all of them join a single new process group, the
CreateNewProcessGroupboolean is certainly sufficient.jozkee commentedon Jun 26, 2025
@jilles-sg I updated the API proposal yesterday to reflect this will be a Windows-only API to unblock sending signals to an isolated process group. There won't be any effects in Unix.
bartonjs commentedon Jul 1, 2025
Video
Looks good as proposed