fix(tracing-core): prevent potential deadlock by retaining Dispatch instances until after lock is released #3275
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.
Motivation
Dropping
Dispatch
instances during a call toregister_callsite
can result in a deadlock.This occurs when a
Dispatch
's associatedSubscriber
implementation performs logging (e.g., viainfo!
) in itsDrop
implementation.Since
info!
internally triggersregister_callsite
, this can re-enter the same lock (LOCKED_DISPATCHERS
) already held during interest rebuilding, causing a deadlock.This PR addresses Issue #3269, which provides a minimal example of the issue.
Solution
This PR introduces a temporary
DispatchGuard
(aVec<Dispatch>
) to retain strong references toDispatch
instances during thefor_each
traversal used in interest rebuilding.By ensuring that these
Dispatch
instances are dropped only after the write lock onLOCKED_DISPATCHERS
has been released,we prevent re-entrant locking in the
Drop
path of aSubscriber
, avoiding the deadlock.