-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Fix class construction recursion issue in Lock
on NativeAOT
#94241
Conversation
- The `Monitor` type was being constructed due to the use of `Monitor.DebugBlockingScope`, added that to the initialization phase - If necessary, an alternative may be to move `DebugBlockingScope` to be under `Lock`. Based on the comments the thread-static field is apparently bound-to in debugging scenarios. - Fixes dotnet#94227
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue Details
|
These comments are left-overs from .NET Native for UWP. No debugger uses this field today. |
Although it did not cause problems before, if it is useless, perhaps removing |
Ah ok, thanks!
Sounds good to me, updated. Something like that could always be added as necessary. |
Yes, we should look into whether there is any diagnostic support required for the new Lock type, across all runtimes. |
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.