[stephenlclarke]

Summary

Avoid recursively acquiring AsyncSignalHandler's state mutex during cancellation.

cancel() previously called AsyncStream.Continuation.finish() while holding the lock. Finishing invokes the continuation's onTermination callback, which calls cancel() again and can deadlock on the same non-recursive mutex.

Drain the continuations and dispatch sources under the lock, clear the shared state, then finish and cancel those resources after releasing the lock. This keeps repeated cancellation idempotent while removing the recursive lock path.

Testing

swift test --filter AsyncSignalHandlerTests

Result: 1 focused regression passed. It creates multiple signal streams, cancels them, verifies both finish, and then cancels again.

Compatibility

No public API changes. Signal sources and streams are still cancelled by the same call; only the lock boundary changes.

[crosbymichael]

Do you think installing a signal handler in the test process could cause issues/flakes?

[stephenlclarke]

Rebased onto current upstream 6adea5663427b4068108e9268e6125fc139b6045 and updated the regression in 19eb7f900324b7999678f0174b1af4474169b45c. The test now uses notify: []: it exercises both stream termination callbacks and repeated cancellation without installing a process-wide signal disposition in the shared test runner.

A standalone executable compiled from the exact production file reproduces the original failure after entering cancel() and before returning; the updated implementation returns, drains both streams, and tolerates repeated cancellation. This is isolated / focused cancellation evidence.