Fix class construction recursion issue in Lock
on NativeAOT
#94241
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.
Monitor
type was being constructed due to the use ofMonitor.DebugBlockingScope
, added that to the initialization phase so that the relevant type is initialized before it's used on the wait pathDebugBlockingScope
to be underLock
, it would probably make more sense forMonitor
to refer toLock
as it already does, than the inverse. Based on the comments the thread-static field is apparently bound-to in debugging scenarios currently. Something to look into, for now this should unblock the CI.