Мне было интересно, в профилировщике фреймворка .net, ExceptionThrown (https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-api/profiling/icorprofilercallback-exceptionthrown-method) гарантированно не перекрывается с GC?
Глядя на документацию, это выглядит так - "Если профилировщик блокирует здесь и мусорпри попытке сбора, среда выполнения будет блокироваться до тех пор, пока этот обратный вызов не вернет "
. Однако я запустил свой профилировщик, подключенный к paint.net (https://www.getpaint.net/ - версия 4.1.6), и увидел конкретный случай, когда яполучил GC во время ExceptionThrown. (но это было очень редко - происходило только при запуске и только один раз в каждые 20 запусков) - что приводило к изменению данных прямо во время чтения, поскольку gc перемещал их.
По крайней мере, в версии ядра .net - https://github.com/dotnet/coreclr/blob/master/Documentation/botr/profiling.md в нем явно указано, какие обратные вызовы безопасны для вызова GC. ExceptionThrown не является одним из них. Например, ExceptionUnwindFunctionEnter. Однако вернемся к .NET framework - https://docs.microsoft.com/en-us/dotnet/framework/unmanaged-api/profiling/icorprofilercallback-exceptionunwindfunctionenter-method - замечание в документации по .NET Framework относительно GC идентично примечанию для ExceptionThrown.
Я знаю, что ядро .NET! = .NET frameworк.Тем не менее, я чувствую, что код их профилировщиков довольно похож и имеет те же гарантии.Я не смог найти подобный ресурс о безопасности GC вокруг обратных вызовов .NET Framework.
Итак, после всего этого вступления у меня возник вопрос:
Следует .NET Frameworkclr profiler ExceptionThrown callback будет GC-безопасным.И если да, то как могло случиться, что я видел, что вызов GC начинается и заканчивается во время ExceptionThrown (возможная ошибка в clr или ожидаемое поведение)?
Если не ошибка, могу ли я хотя бы полагаться на 100% на .NET framework clr profiler Обратный вызов UnwindExceptionFunctionEnter должен быть безопасным для GC на основе аналогичной документации по core-clr?
Thx