Fix race condition: set _canceled before SignalCore in ProcessWaitState

[Copilot]

Description

ProcessSafeHandle_WaitForExitOrKillOnCancellationAsync_KillsOnCancellation fails intermittently in CI because _canceled is set after SignalCore(PosixSignal.SIGKILL) returns. The reaping thread triggered by the kill signal can enter ChildReaped and read _canceled == false before the cancellation/timeout path writes true, producing exitStatus.Canceled == false.

Changes

• Set _canceled = true before calling SignalCore(PosixSignal.SIGKILL) at all call sites (WaitForExitOrKillOnCancellationAsync, WaitForExitOrKillOnTimeoutCore on both Unix and Windows), so the reaping thread always observes the canceled state
• Remove volatile from _canceled since the _gate lock acquire in ChildReaped provides the necessary memory barrier on the read side

[tmds]

Add Cancel(SafeProcessHandle) method to ProcessWaitState.Unix.cs that sets _canceled under _gate lock

Suggestion: remove the volatile, don't take a lock, and do this:

waitState._canceled = true;
SignalCore(PosixSignal.SIGKILL);

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Fixes an intermittent CI failure by ensuring the “canceled” state is set atomically with process reaping on Unix, eliminating a race between the cancellation/timeout path and ChildReaped exit-status construction.

Changes:

• Add a Unix ProcessWaitState.Cancel(SafeProcessHandle) that takes _gate before signaling and setting _canceled.
• Introduce platform-specific SafeProcessHandle.Cancel() helpers and route cancellation/timeout call sites through them (or through the wait state on Unix).
• Remove volatile from _canceled now that access is lock-protected.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
src/libraries/System.Diagnostics.Process/src/System/Diagnostics/ProcessWaitState.Unix.cs	Adds lock-protected cancel path and removes volatile on _canceled to make cancellation state consistent with ChildReaped.
src/libraries/System.Diagnostics.Process/src/Microsoft/Win32/SafeHandles/SafeProcessHandle.cs	Switches cancellation callback to call the new Cancel() helper.
src/libraries/System.Diagnostics.Process/src/Microsoft/Win32/SafeHandles/SafeProcessHandle.Windows.cs	Adds Cancel() helper and uses it for timeout kill path.
src/libraries/System.Diagnostics.Process/src/Microsoft/Win32/SafeHandles/SafeProcessHandle.Unix.cs	Adds Cancel() helper that routes through ProcessWaitState.Cancel, and updates timeout kill path.

[adamsitnik]

Add Cancel(SafeProcessHandle) method to ProcessWaitState.Unix.cs that sets _canceled under _gate lock

Suggestion: remove the volatile, don't take a lock, and do this:

waitState._canceled = true;

SignalCore(PosixSignal.SIGKILL);

@copilot revert all the changes and implement this suggestion.

[Copilot]

Add Cancel(SafeProcessHandle) method to ProcessWaitState.Unix.cs that sets _canceled under _gate lock

...

Reverted all previous changes and implemented the simpler approach in 6bc7251: set _canceled = true before SignalCore(PosixSignal.SIGKILL) at all call sites (Unix timeout, Unix cancellation, Windows timeout, shared cancellation callback), removed volatile from _canceled. No lock needed. All 561 tests pass.

Add Cancel(SafeProcessHandle) method to ProcessWaitState.Unix.cs that sets _canceled under _gate lock

...

Reverted all previous changes and implemented the simpler approach in 6bc72519. At all 3 call sites, _canceled is now set to true before SignalCore(PosixSignal.SIGKILL), and volatile is removed. All 561 tests pass.

[adamsitnik]

/ba-g timeouts are unrelated