You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Move away from exposing internal EventPipe wait handle to EventPipeEventDispatcher. (#68320)
* Move away from exposing internal EventPipe wait handle to EventPipeEventDispatcher.
Fix for issue, #68032.
EventPipe exposed and internal wait handle to EventPipeEventDispatcher.
The wait handle is not a managed WaitableObject, but maps to runtime
specific event types:
CLREventStatic * on CoreCLR
mono_w32event_create on Mono
Overtime it appears that the underlying WaitHandle changed on none Windows
platforms, so calls like:
EventWaitHandle.Set
Assumes that IntPtr used is a WaitableObject and on Mono this will cause
a crash, but on CoreCLR, it will just be casted over to a WaitableObject
and use it, so based on memory layout this could cause issue, but looking
at the implementation, it appears it will always assume EventWaitHandle
is signaled so won't touch any of the memory (but not signal the event).
There have been an ambition in DispatchEventsToEventListeners to move
this abstraction down into native code, get away from using a handle
returned from EventPipeInternal.GetWaitHandle as a EventWaitHandle. This
PR eliminate EventPipeInternal.GetWaitHandle and adds a SignalSession and
WaitForSessionSignal icall's (Mono), qcall's (CoreCLR) and fix the
issue caused by exposing the handle to managed code.
0 commit comments