95b225aef7
Execute() signaled _stopEvent before clearing _pause and before checking the exit flag. Wake/Sleep/Exit all run on the owning thread, so the moment _stopEvent is set the owner can start another pause cycle - Exit() does exactly that. Two interleavings in that window are fatal: - The worker's late "_pause = false" clobbers the new cycle's pause request, so the worker consumes the wake and spins forever waiting for a pause that never reads true while the owner blocks in Sleep(). - The worker's late exit check observes the _exit flag written by an Exit() whose Sleep() is still pending, and returns without ever signaling it. Either way the run hangs silently. The ordering predates this branch, but production callers never sat inside the window (one Wake/Sleep pair per save, minutes apart; Exit only long after the last handshake). The tests added on this branch are the first callers that run pause cycles back-to-back, and a saturated CI runner hit the window: this is what stalled the CentOS job for 2h41m. The race is not rare under that pattern - a churn test reproduces the deadlock in 4 out of 4 runs locally. Fix: sample the exit condition and clear _pause (volatile) BEFORE signaling _stopEvent. A post-signal Exit() is then always serviced by one more wake/drain/signal round, and its pause request can no longer be clobbered. Drain-before-exit semantics on Core.Closing are unchanged. Adds a watchdog churn regression test (2000 wake/sleep/exit lifecycles) that fails instead of hanging if the race is reintroduced: red 4/4 deadlocks without the fix, green 4/4 at ~550ms with it. Server.Tests 789/789 and UOContent.Tests 509/509 pass. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| Buffers | ||
| Client | ||
| Collections | ||
| Console | ||
| Geometry | ||
| Items | ||
| Json | ||
| Localization | ||
| Maps | ||
| Network | ||
| PropertyList | ||
| Serialization | ||
| Text | ||
| Timer | ||
| Utility | ||
| World | ||
| SerialTests.cs | ||