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).

ProcessStartOptions options = new("cmd.exe") { Arguments = { "/c", "echo hello" } };
using SafeProcessHandle handle = SafeProcessHandle.Start(options, input: null, output: null, error: null);
ProcessExitStatus status = 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

	internal static int GetTimeoutInMilliseconds(TimeSpan timeout)
	internal static int ToTimeoutInMilliseconds(TimeSpan timeout)

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