Add new process management APIs to SafeProcessHandle

[Copilot]

Description

Implements the approved API surface for SafeProcessHandle (#123380): process lifecycle management via Start, Open, Kill, Signal, SignalProcessGroup, and WaitForExit overloads. Windows implementation complete; Unix stubs throw NotImplementedException (separate PR).

ProcessStartOptionsoptions=new("cmd.exe"){Arguments={"/c","echo hello"}};usingSafeProcessHandlehandle=SafeProcessHandle.Start(options,input:null,output:null,error:null);ProcessExitStatusstatus=handle.WaitForExit();// status.ExitCode == 0, status.Canceled == false

Public API

• Open(int processId) — opens existing process handle
• Start(ProcessStartOptions, SafeFileHandle?, SafeFileHandle?, SafeFileHandle?) — create process with explicit stdio handles
• Kill() — terminate process
• Signal(PosixSignal) / SignalProcessGroup(PosixSignal) — send signal; accepts raw signal numbers like PosixSignalRegistration.Create
• WaitForExit(), TryWaitForExit(TimeSpan, out ProcessExitStatus?), WaitForExitOrKillOnTimeout(TimeSpan) — synchronous wait
• WaitForExitAsync(CancellationToken), WaitForExitOrKillOnCancellationAsync(CancellationToken) — async wait

Internal for now (pending follow-up): ProcessId, StartSuspended, Resume, KillProcessGroup.

Windows implementation

• STARTUPINFOEX + PROC_THREAD_ATTRIBUTE_HANDLE_LIST for explicit handle inheritance
• Job objects for KillOnParentExit and process group termination (best-effort emulation of Unix process groups)
• DangerousAddRef/DangerousRelease on InheritedHandles in PrepareHandleAllowList and on this in KillCore to prevent use-after-free races with concurrent Dispose
• Interlocked.Exchange for _threadHandle and _processGroupJobHandle in ReleaseHandle; Volatile.Read for _processGroupJobHandle access elsewhere
• Sync wait methods use WaitForSingleObject(SafeProcessHandle, ...) directly — no handle duplication via ProcessWaitHandle
• Async wait methods retain ProcessWaitHandle for RegisterWaitForSingleObject
• NativeMemory.Alloc with two-arg overflow-safe version; typed pointers (IntPtr*, void*)
• OOM-safe handle cleanup in finally; error check immediately after CreateProcess

Architecture — ProcessUtils as shared dependency

• ProcessUtils.cs holds s_processStartLock (ReaderWriterLockSlim) — avoids Process ↔ SafeProcessHandle dependency cycle
• ProcessUtils.Windows.cs holds BuildArgs(string, IList<string>?) and GetEnvironmentVariablesBlock
• Process.Windows.cs acquires write lock; SafeProcessHandle.Windows.cs acquires read lock

Interop additions

• Interop.JobObjects.cs, Interop.ProcThreadAttributeList.cs, Interop.ConsoleCtrl.cs (consolidated), Interop.HandleInformation.cs (extended), Interop.ResumeThread_IntPtr.cs, Interop.WaitForSingleObject_SafeProcessHandle.cs

Tests

• SafeProcessHandleTests.cs — start/kill/wait/timeout/signal tests with Nano Server support (ping fallback); signal tests as [Theory] with [InlineData]

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[jkotas]

Suggested change

	internalstaticintGetTimeoutInMilliseconds(TimeSpantimeout)
	internalstaticintToTimeoutInMilliseconds(TimeSpantimeout)

This method is called ToTimeoutMilliseconds in other places.

We have identical multiple copies of this method. It is candidate for a helper API.

[jkotas]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan. Can we just call those instead?

[adamsitnik]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan.

You are right, on Windows I could just pass TimeSpan to the Core implementation, but on Unix I need raw int milliseconds to pass it to poll and similar sys-calls.

[jkotas]

Nit: Would be simpler to just throw PlatformNotSupportedException from this method unconditionally on Windows, and mark this method as unsupported on Windows? I expect that killing the process is typically going to be done by the Kill API. Handling PosixSignal.SIGKILL here does not have a lot of value.

[adamsitnik]

Handling PosixSignal.SIGKILL here does not have a lot of value.

I agree it's not a lot, but I can imagine that some users with Unix background would prefer using Signal(PosixSignal.SIGKILL) over Kill.

It's not something that I have very strong opinion about.

[jkotas]

LGTM modulo feedback

[jkotas]

Thanks

[adamsitnik]

This PR won't be merged, but it's going to be a "donor" for other PRs (#126313, #126318 and more)

[Copilot]

Description

Implements the approved API surface for SafeProcessHandle (#123380): process lifecycle management via Start, Open, Kill, Signal, SignalProcessGroup, and WaitForExit overloads. Windows implementation complete; Unix stubs throw NotImplementedException (separate PR).

ProcessStartOptionsoptions=new("cmd.exe"){Arguments={"/c","echo hello"}};usingSafeProcessHandlehandle=SafeProcessHandle.Start(options,input:null,output:null,error:null);ProcessExitStatusstatus=handle.WaitForExit();// status.ExitCode == 0, status.Canceled == false

Public API

• Open(int processId) — opens existing process handle
• Start(ProcessStartOptions, SafeFileHandle?, SafeFileHandle?, SafeFileHandle?) — create process with explicit stdio handles
• Kill() — terminate process
• Signal(PosixSignal) / SignalProcessGroup(PosixSignal) — send signal; accepts raw signal numbers like PosixSignalRegistration.Create
• WaitForExit(), TryWaitForExit(TimeSpan, out ProcessExitStatus?), WaitForExitOrKillOnTimeout(TimeSpan) — synchronous wait
• WaitForExitAsync(CancellationToken), WaitForExitOrKillOnCancellationAsync(CancellationToken) — async wait

Internal for now (pending follow-up): ProcessId, StartSuspended, Resume, KillProcessGroup.

Windows implementation

• STARTUPINFOEX + PROC_THREAD_ATTRIBUTE_HANDLE_LIST for explicit handle inheritance
• Job objects for KillOnParentExit and process group termination (best-effort emulation of Unix process groups)
• DangerousAddRef/DangerousRelease on InheritedHandles in PrepareHandleAllowList and on this in KillCore to prevent use-after-free races with concurrent Dispose
• Interlocked.Exchange for _threadHandle and _processGroupJobHandle in ReleaseHandle; Volatile.Read for _processGroupJobHandle access elsewhere
• Sync wait methods use WaitForSingleObject(SafeProcessHandle, ...) directly — no handle duplication via ProcessWaitHandle
• Async wait methods retain ProcessWaitHandle for RegisterWaitForSingleObject
• NativeMemory.Alloc with two-arg overflow-safe version; typed pointers (IntPtr*, void*)
• OOM-safe handle cleanup in finally; error check immediately after CreateProcess

Architecture — ProcessUtils as shared dependency

• ProcessUtils.cs holds s_processStartLock (ReaderWriterLockSlim) — avoids Process ↔ SafeProcessHandle dependency cycle
• ProcessUtils.Windows.cs holds BuildArgs(string, IList<string>?) and GetEnvironmentVariablesBlock
• Process.Windows.cs acquires write lock; SafeProcessHandle.Windows.cs acquires read lock

Interop additions

• Interop.JobObjects.cs, Interop.ProcThreadAttributeList.cs, Interop.ConsoleCtrl.cs (consolidated), Interop.HandleInformation.cs (extended), Interop.ResumeThread_IntPtr.cs, Interop.WaitForSingleObject_SafeProcessHandle.cs

Tests

• SafeProcessHandleTests.cs — start/kill/wait/timeout/signal tests with Nano Server support (ping fallback); signal tests as [Theory] with [InlineData]

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[jkotas]

Suggested change

	internalstaticintGetTimeoutInMilliseconds(TimeSpantimeout)
	internalstaticintToTimeoutInMilliseconds(TimeSpantimeout)

This method is called ToTimeoutMilliseconds in other places.

We have identical multiple copies of this method. It is candidate for a helper API.

[jkotas]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan. Can we just call those instead?

[adamsitnik]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan.

You are right, on Windows I could just pass TimeSpan to the Core implementation, but on Unix I need raw int milliseconds to pass it to poll and similar sys-calls.

[jkotas]

Nit: Would be simpler to just throw PlatformNotSupportedException from this method unconditionally on Windows, and mark this method as unsupported on Windows? I expect that killing the process is typically going to be done by the Kill API. Handling PosixSignal.SIGKILL here does not have a lot of value.

[adamsitnik]

Handling PosixSignal.SIGKILL here does not have a lot of value.

I agree it's not a lot, but I can imagine that some users with Unix background would prefer using Signal(PosixSignal.SIGKILL) over Kill.

It's not something that I have very strong opinion about.

[jkotas]

LGTM modulo feedback

[jkotas]

Thanks

[adamsitnik]

This PR won't be merged, but it's going to be a "donor" for other PRs (#126313, #126318 and more)

[Copilot]

Description

Implements the approved API surface for SafeProcessHandle (#123380): process lifecycle management via Start, Open, Kill, Signal, SignalProcessGroup, and WaitForExit overloads. Windows implementation complete; Unix stubs throw NotImplementedException (separate PR).

ProcessStartOptionsoptions=new("cmd.exe"){Arguments={"/c","echo hello"}};usingSafeProcessHandlehandle=SafeProcessHandle.Start(options,input:null,output:null,error:null);ProcessExitStatusstatus=handle.WaitForExit();// status.ExitCode == 0, status.Canceled == false

Public API

• Open(int processId) — opens existing process handle
• Start(ProcessStartOptions, SafeFileHandle?, SafeFileHandle?, SafeFileHandle?) — create process with explicit stdio handles
• Kill() — terminate process
• Signal(PosixSignal) / SignalProcessGroup(PosixSignal) — send signal; accepts raw signal numbers like PosixSignalRegistration.Create
• WaitForExit(), TryWaitForExit(TimeSpan, out ProcessExitStatus?), WaitForExitOrKillOnTimeout(TimeSpan) — synchronous wait
• WaitForExitAsync(CancellationToken), WaitForExitOrKillOnCancellationAsync(CancellationToken) — async wait

Internal for now (pending follow-up): ProcessId, StartSuspended, Resume, KillProcessGroup.

Windows implementation

• STARTUPINFOEX + PROC_THREAD_ATTRIBUTE_HANDLE_LIST for explicit handle inheritance
• Job objects for KillOnParentExit and process group termination (best-effort emulation of Unix process groups)
• DangerousAddRef/DangerousRelease on InheritedHandles in PrepareHandleAllowList and on this in KillCore to prevent use-after-free races with concurrent Dispose
• Interlocked.Exchange for _threadHandle and _processGroupJobHandle in ReleaseHandle; Volatile.Read for _processGroupJobHandle access elsewhere
• Sync wait methods use WaitForSingleObject(SafeProcessHandle, ...) directly — no handle duplication via ProcessWaitHandle
• Async wait methods retain ProcessWaitHandle for RegisterWaitForSingleObject
• NativeMemory.Alloc with two-arg overflow-safe version; typed pointers (IntPtr*, void*)
• OOM-safe handle cleanup in finally; error check immediately after CreateProcess

Architecture — ProcessUtils as shared dependency

• ProcessUtils.cs holds s_processStartLock (ReaderWriterLockSlim) — avoids Process ↔ SafeProcessHandle dependency cycle
• ProcessUtils.Windows.cs holds BuildArgs(string, IList<string>?) and GetEnvironmentVariablesBlock
• Process.Windows.cs acquires write lock; SafeProcessHandle.Windows.cs acquires read lock

Interop additions

• Interop.JobObjects.cs, Interop.ProcThreadAttributeList.cs, Interop.ConsoleCtrl.cs (consolidated), Interop.HandleInformation.cs (extended), Interop.ResumeThread_IntPtr.cs, Interop.WaitForSingleObject_SafeProcessHandle.cs

Tests

• SafeProcessHandleTests.cs — start/kill/wait/timeout/signal tests with Nano Server support (ping fallback); signal tests as [Theory] with [InlineData]

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[jkotas]

Suggested change

	internalstaticintGetTimeoutInMilliseconds(TimeSpantimeout)
	internalstaticintToTimeoutInMilliseconds(TimeSpantimeout)

This method is called ToTimeoutMilliseconds in other places.

We have identical multiple copies of this method. It is candidate for a helper API.

[jkotas]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan. Can we just call those instead?

[adamsitnik]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan.

You are right, on Windows I could just pass TimeSpan to the Core implementation, but on Unix I need raw int milliseconds to pass it to poll and similar sys-calls.

[jkotas]

Nit: Would be simpler to just throw PlatformNotSupportedException from this method unconditionally on Windows, and mark this method as unsupported on Windows? I expect that killing the process is typically going to be done by the Kill API. Handling PosixSignal.SIGKILL here does not have a lot of value.

[adamsitnik]

Handling PosixSignal.SIGKILL here does not have a lot of value.

I agree it's not a lot, but I can imagine that some users with Unix background would prefer using Signal(PosixSignal.SIGKILL) over Kill.

It's not something that I have very strong opinion about.

[jkotas]

LGTM modulo feedback

[jkotas]

Thanks

[adamsitnik]

This PR won't be merged, but it's going to be a "donor" for other PRs (#126313, #126318 and more)

[Copilot]

Description

Implements the approved API surface for SafeProcessHandle (#123380): process lifecycle management via Start, Open, Kill, Signal, SignalProcessGroup, and WaitForExit overloads. Windows implementation complete; Unix stubs throw NotImplementedException (separate PR).

ProcessStartOptionsoptions=new("cmd.exe"){Arguments={"/c","echo hello"}};usingSafeProcessHandlehandle=SafeProcessHandle.Start(options,input:null,output:null,error:null);ProcessExitStatusstatus=handle.WaitForExit();// status.ExitCode == 0, status.Canceled == false

Public API

• Open(int processId) — opens existing process handle
• Start(ProcessStartOptions, SafeFileHandle?, SafeFileHandle?, SafeFileHandle?) — create process with explicit stdio handles
• Kill() — terminate process
• Signal(PosixSignal) / SignalProcessGroup(PosixSignal) — send signal; accepts raw signal numbers like PosixSignalRegistration.Create
• WaitForExit(), TryWaitForExit(TimeSpan, out ProcessExitStatus?), WaitForExitOrKillOnTimeout(TimeSpan) — synchronous wait
• WaitForExitAsync(CancellationToken), WaitForExitOrKillOnCancellationAsync(CancellationToken) — async wait

Internal for now (pending follow-up): ProcessId, StartSuspended, Resume, KillProcessGroup.

Windows implementation

• STARTUPINFOEX + PROC_THREAD_ATTRIBUTE_HANDLE_LIST for explicit handle inheritance
• Job objects for KillOnParentExit and process group termination (best-effort emulation of Unix process groups)
• DangerousAddRef/DangerousRelease on InheritedHandles in PrepareHandleAllowList and on this in KillCore to prevent use-after-free races with concurrent Dispose
• Interlocked.Exchange for _threadHandle and _processGroupJobHandle in ReleaseHandle; Volatile.Read for _processGroupJobHandle access elsewhere
• Sync wait methods use WaitForSingleObject(SafeProcessHandle, ...) directly — no handle duplication via ProcessWaitHandle
• Async wait methods retain ProcessWaitHandle for RegisterWaitForSingleObject
• NativeMemory.Alloc with two-arg overflow-safe version; typed pointers (IntPtr*, void*)
• OOM-safe handle cleanup in finally; error check immediately after CreateProcess

Architecture — ProcessUtils as shared dependency

• ProcessUtils.cs holds s_processStartLock (ReaderWriterLockSlim) — avoids Process ↔ SafeProcessHandle dependency cycle
• ProcessUtils.Windows.cs holds BuildArgs(string, IList<string>?) and GetEnvironmentVariablesBlock
• Process.Windows.cs acquires write lock; SafeProcessHandle.Windows.cs acquires read lock

Interop additions

• Interop.JobObjects.cs, Interop.ProcThreadAttributeList.cs, Interop.ConsoleCtrl.cs (consolidated), Interop.HandleInformation.cs (extended), Interop.ResumeThread_IntPtr.cs, Interop.WaitForSingleObject_SafeProcessHandle.cs

Tests

• SafeProcessHandleTests.cs — start/kill/wait/timeout/signal tests with Nano Server support (ping fallback); signal tests as [Theory] with [InlineData]

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[jkotas]

Suggested change

	internalstaticintGetTimeoutInMilliseconds(TimeSpantimeout)
	internalstaticintToTimeoutInMilliseconds(TimeSpantimeout)

This method is called ToTimeoutMilliseconds in other places.

We have identical multiple copies of this method. It is candidate for a helper API.

[jkotas]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan. Can we just call those instead?

[adamsitnik]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan.

You are right, on Windows I could just pass TimeSpan to the Core implementation, but on Unix I need raw int milliseconds to pass it to poll and similar sys-calls.

[jkotas]

Nit: Would be simpler to just throw PlatformNotSupportedException from this method unconditionally on Windows, and mark this method as unsupported on Windows? I expect that killing the process is typically going to be done by the Kill API. Handling PosixSignal.SIGKILL here does not have a lot of value.

[adamsitnik]

Handling PosixSignal.SIGKILL here does not have a lot of value.

I agree it's not a lot, but I can imagine that some users with Unix background would prefer using Signal(PosixSignal.SIGKILL) over Kill.

It's not something that I have very strong opinion about.

[jkotas]

LGTM modulo feedback

[jkotas]

Thanks

[adamsitnik]

This PR won't be merged, but it's going to be a "donor" for other PRs (#126313, #126318 and more)

[Copilot]

Description

Implements the approved API surface for SafeProcessHandle (#123380): process lifecycle management via Start, Open, Kill, Signal, SignalProcessGroup, and WaitForExit overloads. Windows implementation complete; Unix stubs throw NotImplementedException (separate PR).

ProcessStartOptionsoptions=new("cmd.exe"){Arguments={"/c","echo hello"}};usingSafeProcessHandlehandle=SafeProcessHandle.Start(options,input:null,output:null,error:null);ProcessExitStatusstatus=handle.WaitForExit();// status.ExitCode == 0, status.Canceled == false

Public API

• Open(int processId) — opens existing process handle
• Start(ProcessStartOptions, SafeFileHandle?, SafeFileHandle?, SafeFileHandle?) — create process with explicit stdio handles
• Kill() — terminate process
• Signal(PosixSignal) / SignalProcessGroup(PosixSignal) — send signal; accepts raw signal numbers like PosixSignalRegistration.Create
• WaitForExit(), TryWaitForExit(TimeSpan, out ProcessExitStatus?), WaitForExitOrKillOnTimeout(TimeSpan) — synchronous wait
• WaitForExitAsync(CancellationToken), WaitForExitOrKillOnCancellationAsync(CancellationToken) — async wait

Internal for now (pending follow-up): ProcessId, StartSuspended, Resume, KillProcessGroup.

Windows implementation

• STARTUPINFOEX + PROC_THREAD_ATTRIBUTE_HANDLE_LIST for explicit handle inheritance
• Job objects for KillOnParentExit and process group termination (best-effort emulation of Unix process groups)
• DangerousAddRef/DangerousRelease on InheritedHandles in PrepareHandleAllowList and on this in KillCore to prevent use-after-free races with concurrent Dispose
• Interlocked.Exchange for _threadHandle and _processGroupJobHandle in ReleaseHandle; Volatile.Read for _processGroupJobHandle access elsewhere
• Sync wait methods use WaitForSingleObject(SafeProcessHandle, ...) directly — no handle duplication via ProcessWaitHandle
• Async wait methods retain ProcessWaitHandle for RegisterWaitForSingleObject
• NativeMemory.Alloc with two-arg overflow-safe version; typed pointers (IntPtr*, void*)
• OOM-safe handle cleanup in finally; error check immediately after CreateProcess

Architecture — ProcessUtils as shared dependency

• ProcessUtils.cs holds s_processStartLock (ReaderWriterLockSlim) — avoids Process ↔ SafeProcessHandle dependency cycle
• ProcessUtils.Windows.cs holds BuildArgs(string, IList<string>?) and GetEnvironmentVariablesBlock
• Process.Windows.cs acquires write lock; SafeProcessHandle.Windows.cs acquires read lock

Interop additions

• Interop.JobObjects.cs, Interop.ProcThreadAttributeList.cs, Interop.ConsoleCtrl.cs (consolidated), Interop.HandleInformation.cs (extended), Interop.ResumeThread_IntPtr.cs, Interop.WaitForSingleObject_SafeProcessHandle.cs

Tests

• SafeProcessHandleTests.cs — start/kill/wait/timeout/signal tests with Nano Server support (ping fallback); signal tests as [Theory] with [InlineData]

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[jkotas]

Suggested change

	internalstaticintGetTimeoutInMilliseconds(TimeSpantimeout)
	internalstaticintToTimeoutInMilliseconds(TimeSpantimeout)

This method is called ToTimeoutMilliseconds in other places.

We have identical multiple copies of this method. It is candidate for a helper API.

[jkotas]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan. Can we just call those instead?

[adamsitnik]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan.

You are right, on Windows I could just pass TimeSpan to the Core implementation, but on Unix I need raw int milliseconds to pass it to poll and similar sys-calls.

[jkotas]

Nit: Would be simpler to just throw PlatformNotSupportedException from this method unconditionally on Windows, and mark this method as unsupported on Windows? I expect that killing the process is typically going to be done by the Kill API. Handling PosixSignal.SIGKILL here does not have a lot of value.

[adamsitnik]

Handling PosixSignal.SIGKILL here does not have a lot of value.

I agree it's not a lot, but I can imagine that some users with Unix background would prefer using Signal(PosixSignal.SIGKILL) over Kill.

It's not something that I have very strong opinion about.

[jkotas]

LGTM modulo feedback

[jkotas]

Thanks

[adamsitnik]

This PR won't be merged, but it's going to be a "donor" for other PRs (#126313, #126318 and more)

[Copilot]

Description

Implements the approved API surface for SafeProcessHandle (#123380): process lifecycle management via Start, Open, Kill, Signal, SignalProcessGroup, and WaitForExit overloads. Windows implementation complete; Unix stubs throw NotImplementedException (separate PR).

ProcessStartOptionsoptions=new("cmd.exe"){Arguments={"/c","echo hello"}};usingSafeProcessHandlehandle=SafeProcessHandle.Start(options,input:null,output:null,error:null);ProcessExitStatusstatus=handle.WaitForExit();// status.ExitCode == 0, status.Canceled == false

Public API

• Open(int processId) — opens existing process handle
• Start(ProcessStartOptions, SafeFileHandle?, SafeFileHandle?, SafeFileHandle?) — create process with explicit stdio handles
• Kill() — terminate process
• Signal(PosixSignal) / SignalProcessGroup(PosixSignal) — send signal; accepts raw signal numbers like PosixSignalRegistration.Create
• WaitForExit(), TryWaitForExit(TimeSpan, out ProcessExitStatus?), WaitForExitOrKillOnTimeout(TimeSpan) — synchronous wait
• WaitForExitAsync(CancellationToken), WaitForExitOrKillOnCancellationAsync(CancellationToken) — async wait

Internal for now (pending follow-up): ProcessId, StartSuspended, Resume, KillProcessGroup.

Windows implementation

• STARTUPINFOEX + PROC_THREAD_ATTRIBUTE_HANDLE_LIST for explicit handle inheritance
• Job objects for KillOnParentExit and process group termination (best-effort emulation of Unix process groups)
• DangerousAddRef/DangerousRelease on InheritedHandles in PrepareHandleAllowList and on this in KillCore to prevent use-after-free races with concurrent Dispose
• Interlocked.Exchange for _threadHandle and _processGroupJobHandle in ReleaseHandle; Volatile.Read for _processGroupJobHandle access elsewhere
• Sync wait methods use WaitForSingleObject(SafeProcessHandle, ...) directly — no handle duplication via ProcessWaitHandle
• Async wait methods retain ProcessWaitHandle for RegisterWaitForSingleObject
• NativeMemory.Alloc with two-arg overflow-safe version; typed pointers (IntPtr*, void*)
• OOM-safe handle cleanup in finally; error check immediately after CreateProcess

Architecture — ProcessUtils as shared dependency

• ProcessUtils.cs holds s_processStartLock (ReaderWriterLockSlim) — avoids Process ↔ SafeProcessHandle dependency cycle
• ProcessUtils.Windows.cs holds BuildArgs(string, IList<string>?) and GetEnvironmentVariablesBlock
• Process.Windows.cs acquires write lock; SafeProcessHandle.Windows.cs acquires read lock

Interop additions

• Interop.JobObjects.cs, Interop.ProcThreadAttributeList.cs, Interop.ConsoleCtrl.cs (consolidated), Interop.HandleInformation.cs (extended), Interop.ResumeThread_IntPtr.cs, Interop.WaitForSingleObject_SafeProcessHandle.cs

Tests

• SafeProcessHandleTests.cs — start/kill/wait/timeout/signal tests with Nano Server support (ping fallback); signal tests as [Theory] with [InlineData]

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[jkotas]

Suggested change

	internalstaticintGetTimeoutInMilliseconds(TimeSpantimeout)
	internalstaticintToTimeoutInMilliseconds(TimeSpantimeout)

This method is called ToTimeoutMilliseconds in other places.

We have identical multiple copies of this method. It is candidate for a helper API.

[jkotas]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan. Can we just call those instead?

[adamsitnik]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan.

You are right, on Windows I could just pass TimeSpan to the Core implementation, but on Unix I need raw int milliseconds to pass it to poll and similar sys-calls.

[jkotas]

Nit: Would be simpler to just throw PlatformNotSupportedException from this method unconditionally on Windows, and mark this method as unsupported on Windows? I expect that killing the process is typically going to be done by the Kill API. Handling PosixSignal.SIGKILL here does not have a lot of value.

[adamsitnik]

Handling PosixSignal.SIGKILL here does not have a lot of value.

I agree it's not a lot, but I can imagine that some users with Unix background would prefer using Signal(PosixSignal.SIGKILL) over Kill.

It's not something that I have very strong opinion about.

[jkotas]

LGTM modulo feedback

[jkotas]

Thanks

[adamsitnik]

This PR won't be merged, but it's going to be a "donor" for other PRs (#126313, #126318 and more)

[Copilot]

Description

Implements the approved API surface for SafeProcessHandle (#123380): process lifecycle management via Start, Open, Kill, Signal, SignalProcessGroup, and WaitForExit overloads. Windows implementation complete; Unix stubs throw NotImplementedException (separate PR).

ProcessStartOptionsoptions=new("cmd.exe"){Arguments={"/c","echo hello"}};usingSafeProcessHandlehandle=SafeProcessHandle.Start(options,input:null,output:null,error:null);ProcessExitStatusstatus=handle.WaitForExit();// status.ExitCode == 0, status.Canceled == false

Public API

• Open(int processId) — opens existing process handle
• Start(ProcessStartOptions, SafeFileHandle?, SafeFileHandle?, SafeFileHandle?) — create process with explicit stdio handles
• Kill() — terminate process
• Signal(PosixSignal) / SignalProcessGroup(PosixSignal) — send signal; accepts raw signal numbers like PosixSignalRegistration.Create
• WaitForExit(), TryWaitForExit(TimeSpan, out ProcessExitStatus?), WaitForExitOrKillOnTimeout(TimeSpan) — synchronous wait
• WaitForExitAsync(CancellationToken), WaitForExitOrKillOnCancellationAsync(CancellationToken) — async wait

Internal for now (pending follow-up): ProcessId, StartSuspended, Resume, KillProcessGroup.

Windows implementation

• STARTUPINFOEX + PROC_THREAD_ATTRIBUTE_HANDLE_LIST for explicit handle inheritance
• Job objects for KillOnParentExit and process group termination (best-effort emulation of Unix process groups)
• DangerousAddRef/DangerousRelease on InheritedHandles in PrepareHandleAllowList and on this in KillCore to prevent use-after-free races with concurrent Dispose
• Interlocked.Exchange for _threadHandle and _processGroupJobHandle in ReleaseHandle; Volatile.Read for _processGroupJobHandle access elsewhere
• Sync wait methods use WaitForSingleObject(SafeProcessHandle, ...) directly — no handle duplication via ProcessWaitHandle
• Async wait methods retain ProcessWaitHandle for RegisterWaitForSingleObject
• NativeMemory.Alloc with two-arg overflow-safe version; typed pointers (IntPtr*, void*)
• OOM-safe handle cleanup in finally; error check immediately after CreateProcess

Architecture — ProcessUtils as shared dependency

• ProcessUtils.cs holds s_processStartLock (ReaderWriterLockSlim) — avoids Process ↔ SafeProcessHandle dependency cycle
• ProcessUtils.Windows.cs holds BuildArgs(string, IList<string>?) and GetEnvironmentVariablesBlock
• Process.Windows.cs acquires write lock; SafeProcessHandle.Windows.cs acquires read lock

Interop additions

• Interop.JobObjects.cs, Interop.ProcThreadAttributeList.cs, Interop.ConsoleCtrl.cs (consolidated), Interop.HandleInformation.cs (extended), Interop.ResumeThread_IntPtr.cs, Interop.WaitForSingleObject_SafeProcessHandle.cs

Tests

• SafeProcessHandleTests.cs — start/kill/wait/timeout/signal tests with Nano Server support (ping fallback); signal tests as [Theory] with [InlineData]

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[jkotas]

Suggested change

	internalstaticintGetTimeoutInMilliseconds(TimeSpantimeout)
	internalstaticintToTimeoutInMilliseconds(TimeSpantimeout)

This method is called ToTimeoutMilliseconds in other places.

We have identical multiple copies of this method. It is candidate for a helper API.

[jkotas]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan. Can we just call those instead?

[adamsitnik]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan.

You are right, on Windows I could just pass TimeSpan to the Core implementation, but on Unix I need raw int milliseconds to pass it to poll and similar sys-calls.

[jkotas]

Nit: Would be simpler to just throw PlatformNotSupportedException from this method unconditionally on Windows, and mark this method as unsupported on Windows? I expect that killing the process is typically going to be done by the Kill API. Handling PosixSignal.SIGKILL here does not have a lot of value.

[adamsitnik]

Handling PosixSignal.SIGKILL here does not have a lot of value.

I agree it's not a lot, but I can imagine that some users with Unix background would prefer using Signal(PosixSignal.SIGKILL) over Kill.

It's not something that I have very strong opinion about.

[jkotas]

LGTM modulo feedback

[jkotas]

Thanks

[adamsitnik]

This PR won't be merged, but it's going to be a "donor" for other PRs (#126313, #126318 and more)

[Copilot]

Description

Implements the approved API surface for SafeProcessHandle (#123380): process lifecycle management via Start, Open, Kill, Signal, SignalProcessGroup, and WaitForExit overloads. Windows implementation complete; Unix stubs throw NotImplementedException (separate PR).

ProcessStartOptionsoptions=new("cmd.exe"){Arguments={"/c","echo hello"}};usingSafeProcessHandlehandle=SafeProcessHandle.Start(options,input:null,output:null,error:null);ProcessExitStatusstatus=handle.WaitForExit();// status.ExitCode == 0, status.Canceled == false

Public API

• Open(int processId) — opens existing process handle
• Start(ProcessStartOptions, SafeFileHandle?, SafeFileHandle?, SafeFileHandle?) — create process with explicit stdio handles
• Kill() — terminate process
• Signal(PosixSignal) / SignalProcessGroup(PosixSignal) — send signal; accepts raw signal numbers like PosixSignalRegistration.Create
• WaitForExit(), TryWaitForExit(TimeSpan, out ProcessExitStatus?), WaitForExitOrKillOnTimeout(TimeSpan) — synchronous wait
• WaitForExitAsync(CancellationToken), WaitForExitOrKillOnCancellationAsync(CancellationToken) — async wait

Internal for now (pending follow-up): ProcessId, StartSuspended, Resume, KillProcessGroup.

Windows implementation

• STARTUPINFOEX + PROC_THREAD_ATTRIBUTE_HANDLE_LIST for explicit handle inheritance
• Job objects for KillOnParentExit and process group termination (best-effort emulation of Unix process groups)
• DangerousAddRef/DangerousRelease on InheritedHandles in PrepareHandleAllowList and on this in KillCore to prevent use-after-free races with concurrent Dispose
• Interlocked.Exchange for _threadHandle and _processGroupJobHandle in ReleaseHandle; Volatile.Read for _processGroupJobHandle access elsewhere
• Sync wait methods use WaitForSingleObject(SafeProcessHandle, ...) directly — no handle duplication via ProcessWaitHandle
• Async wait methods retain ProcessWaitHandle for RegisterWaitForSingleObject
• NativeMemory.Alloc with two-arg overflow-safe version; typed pointers (IntPtr*, void*)
• OOM-safe handle cleanup in finally; error check immediately after CreateProcess

Architecture — ProcessUtils as shared dependency

• ProcessUtils.cs holds s_processStartLock (ReaderWriterLockSlim) — avoids Process ↔ SafeProcessHandle dependency cycle
• ProcessUtils.Windows.cs holds BuildArgs(string, IList<string>?) and GetEnvironmentVariablesBlock
• Process.Windows.cs acquires write lock; SafeProcessHandle.Windows.cs acquires read lock

Interop additions

• Interop.JobObjects.cs, Interop.ProcThreadAttributeList.cs, Interop.ConsoleCtrl.cs (consolidated), Interop.HandleInformation.cs (extended), Interop.ResumeThread_IntPtr.cs, Interop.WaitForSingleObject_SafeProcessHandle.cs

Tests

• SafeProcessHandleTests.cs — start/kill/wait/timeout/signal tests with Nano Server support (ping fallback); signal tests as [Theory] with [InlineData]

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[jkotas]

Suggested change

	internalstaticintGetTimeoutInMilliseconds(TimeSpantimeout)
	internalstaticintToTimeoutInMilliseconds(TimeSpantimeout)

This method is called ToTimeoutMilliseconds in other places.

We have identical multiple copies of this method. It is candidate for a helper API.

[jkotas]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan. Can we just call those instead?

[adamsitnik]

Do we actually need to convert the TimeSpan to int here? There are WaitHandle overloads that take TimeSpan.

You are right, on Windows I could just pass TimeSpan to the Core implementation, but on Unix I need raw int milliseconds to pass it to poll and similar sys-calls.

[jkotas]

Nit: Would be simpler to just throw PlatformNotSupportedException from this method unconditionally on Windows, and mark this method as unsupported on Windows? I expect that killing the process is typically going to be done by the Kill API. Handling PosixSignal.SIGKILL here does not have a lot of value.

[adamsitnik]

Handling PosixSignal.SIGKILL here does not have a lot of value.

I agree it's not a lot, but I can imagine that some users with Unix background would prefer using Signal(PosixSignal.SIGKILL) over Kill.

It's not something that I have very strong opinion about.

[jkotas]

LGTM modulo feedback

[jkotas]

Thanks

[adamsitnik]

This PR won't be merged, but it's going to be a "donor" for other PRs (#126313, #126318 and more)