-
Notifications
You must be signed in to change notification settings - Fork 933
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid recursive snatch lock acquisitions #5426
Conversation
d3d9643
to
315bbf3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you very much for this fix!
Indeed not as nice to read as a solution than the recursive lock, but I think @jimblandy is right, this version is the way to go.
Extra thanks for adding the debug assertion in there to capture this sooner in the future.
Bunch of smaller things to fix up and then good to go!
Please also add a changelog entry about this fix.
4eae76f
to
108c086
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, but changelog entry is still missing!
Connections
Bug report: #5279
This PR is an alternative to #5400.
Description
Pass
&SnatchGuard
down to all functions needing it, instead of having them recursively acquire one.This also adds some instrumentation to the
SnatchLock
API that will panic on any attempts to acquire it recursively (gated behindcfg(debug_assertions)
). That should allow the test suite to catch any future misuse of the API, instead of silently making wgpu more deadlock-prone in multi-threaded applications.Testing
cargo xtask test
locally and on CIChecklist
cargo fmt
.cargo clippy
. If applicable, add:--target wasm32-unknown-unknown
--target wasm32-unknown-emscripten
cargo xtask test
to run tests.CHANGELOG.md
. See simple instructions inside file.