Repository navigation
wd33c93a: stop the worker without losing its wakeup - #446
Merged
techomancer merged 1 commit intoNov 7, 2026
Merged
Conversation
The worker checks `running` with the state lock held and then waits on the condition variable, which releases the lock. stop() cleared `running` and notified without taking that lock, so a stop landing between the worker's check and its wait woke nobody: the worker slept on, and the join in stop() waited forever. A stopping machine hung in Hpc3::stop with the WD33C93A thread parked in its wait (seen in stopping_the_disks_comes_before_stopping_the_graphics, twice in about 130 lib test runs at 224 test threads). Clear `running` under the lock.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stopping an Indy or Indigo2 could hang forever. The WD33C93A SCSI controller's
stop()clearedrunningand notified its worker without holding the state lock, so a stop that landed between the worker checkingrunningand going to sleep was lost: the worker slept on andstop()waited for it forever. In iris-gui that is a Stop that never finishes; in the lib tests it hung the run twice in about 130 runs.stop()now clearsrunningwhile holding the lock, so the worker either sees it or gets the wakeup.Testing
cargo test --release --features jitv2 --libandcargo test --features jitv2 --lib: all pass.cargo check -p iris-gui --all-targetsis clean.