Remove deadlock potential from UncapturedErrorHandler
.
#8011
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.
Connections
Fixes #5395.
Description
Previously, the
Device::on_uncaptured_error()
callback was called with a device-wide mutex held. This provides synchronization we don’t actually promise to the user and which the user cannot take advantage of (because the callback signature is notFnMut
), and allows a deadlock to occur via reentrancy.Instead,
Arc
instead ofBox
, and require it to beSend + Sync
rather than justSend
.An alternative to the approach in this PR would be to explicitly document that the callback is called with a mutex held. In that case, the callback should be made
FnMut
to allow it to take advantage of this — the opposite of this PR's change toFn + Sync
.Testing
Added a test case for the now-impossible deadlock.
Squash or Rebase?
Rebase.
Checklist
cargo fmt
.taplo format
.cargo clippy --tests
. If applicable, add:--target wasm32-unknown-unknown
cargo xtask test
to run tests.CHANGELOG.md
entry.