Commits on Nov 11, 2020

1. Allow suspending the runtime while suspension for the debugger is pen… …

   …ding in some cases
   
   1. When suspending for the debugger is in progress (the debugger is waiting for some threads to reach a safe point for suspension), a thread that is not yet suspended may trigger another runtime suspension. This is currently not allowed because the order of operations conflicts with requirements to send GC events for managed data breakpoints to work correctly when suspending for a GC. Instead, the thread suspends for the debugger first, and after the runtime is resumed, continues suspending for GC.
   2. At the same time, if the thread that is not suspended yet is in a forbid-suspend-for-debugger region, it cannot suspend for the debugger, which conflicts with the above scenario, but is currently necessary for the issue fixed by dotnet#40060
   3. The current plan is to change managed data breakpoints implementation to pin objects instead of using GC events to track object relocation, and to deprecate the GC events APIs
   4. With that, the requirement in #1 goes away, so this change conditions the check to avoid suspending the runtime during a pending suspension for the debugger when GC events are not enabled
   
   - Verified that the latest deadlock seen in dotnet#42375 manifests only when a data breakpoint set and not otherwise
   - Combined with dotnet#44471 and a VS update to use that to switch to the pinning mechanism, the deadlock issue seen above should disappear completely

   

   kouvel committed Nov 11, 2020
   Configuration menu

   • View commit details
   • Copy full SHA for b94de53
   • Browse repository at this point

   Copy the full SHA

   b94de53 View commit details

   Browse the repository at this point in the history