diff options
| author | Sung Yoon Whang <suwhang@microsoft.com> | 2019-06-20 16:33:51 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-06-20 16:33:51 -0700 |
| commit | 9bd2787a9dd2aa4d2b7d4f72afebc3dbe896e896 (patch) | |
| tree | 712b8829d3aa9d9d9ac936c8f4b914503bdcdae7 /src/vm/win32threadpool.cpp | |
| parent | 05a557349f6c60f014f708282762168a8ba093e0 (diff) | |
| download | coreclr-9bd2787a9dd2aa4d2b7d4f72afebc3dbe896e896.tar.gz coreclr-9bd2787a9dd2aa4d2b7d4f72afebc3dbe896e896.tar.bz2 coreclr-9bd2787a9dd2aa4d2b7d4f72afebc3dbe896e896.zip | |
Fix eventpipe filtering (#25221)
* Add DOTNET_TRACE_CONTEXT and change macros to use DOTNET_TRACE_CONTEXT instead of MCGEN_TRACE_CONTEXT
* Fixing macro definitions
* eventing codegen scripts now generates EventPipe trace contexts
* Fix macros to use the EVENTPIPE_TRACE_Context
* Fix linux build
* Fix windows build
* Update Eventpipe provider context at EtwCallbackComon
* break in switch
* Update rundown provider context manually
* PR feedback
* Eventpipe->EventPipe
* cleanup in codegen script
Diffstat (limited to 'src/vm/win32threadpool.cpp')
| -rw-r--r-- | src/vm/win32threadpool.cpp | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/src/vm/win32threadpool.cpp b/src/vm/win32threadpool.cpp index 2f0625ace4..1ec90c54bc 100644 --- a/src/vm/win32threadpool.cpp +++ b/src/vm/win32threadpool.cpp @@ -2309,7 +2309,7 @@ BOOL ThreadpoolMgr::RegisterWaitForSingleObject(PHANDLE phNewWaitObject, // We fire the "enqueue" ETW event here, to "mark" the thread that had called the API, rather than the // thread that will PostQueuedCompletionStatus (the dedicated WaitThread). // This event correlates with ThreadPoolIODequeue in ThreadpoolMgr::AsyncCallbackCompletion - if (ETW_EVENT_ENABLED(MICROSOFT_WINDOWS_DOTNETRUNTIME_PROVIDER_Context, ThreadPoolIOEnqueue)) + if (ETW_EVENT_ENABLED(MICROSOFT_WINDOWS_DOTNETRUNTIME_PROVIDER_DOTNET_Context, ThreadPoolIOEnqueue)) FireEtwThreadPoolIOEnqueue((LPOVERLAPPED)waitInfo, reinterpret_cast<void*>(Callback), (dwFlag & WAIT_SINGLE_EXECUTION) == 0, GetClrInstanceId()); BOOL status = QueueUserAPC((PAPCFUNC)InsertNewWaitForSelf, threadCB->threadHandle, (size_t) waitInfo); @@ -2867,7 +2867,7 @@ DWORD WINAPI ThreadpoolMgr::AsyncCallbackCompletion(PVOID pArgs) // We fire the "dequeue" ETW event here, before executing the user code, to enable correlation with // the ThreadPoolIOEnqueue fired in ThreadpoolMgr::RegisterWaitForSingleObject - if (ETW_EVENT_ENABLED(MICROSOFT_WINDOWS_DOTNETRUNTIME_PROVIDER_Context, ThreadPoolIODequeue)) + if (ETW_EVENT_ENABLED(MICROSOFT_WINDOWS_DOTNETRUNTIME_PROVIDER_DOTNET_Context, ThreadPoolIODequeue)) FireEtwThreadPoolIODequeue(waitInfo, reinterpret_cast<void*>(waitInfo->Callback), GetClrInstanceId()); // the user callback can throw, the host must be prepared to handle it. @@ -3427,7 +3427,7 @@ Top: // Note: we still fire the event for managed async IO, despite the fact we don't have a paired IOEnqueue event // for this case. We do this to "mark" the end of the previous workitem. When we provide full support at the higher // abstraction level for managed IO we can remove the IODequeues fired here - if (ETW_EVENT_ENABLED(MICROSOFT_WINDOWS_DOTNETRUNTIME_PROVIDER_Context, ThreadPoolIODequeue) + if (ETW_EVENT_ENABLED(MICROSOFT_WINDOWS_DOTNETRUNTIME_PROVIDER_DOTNET_Context, ThreadPoolIODequeue) && !AreEtwIOQueueEventsSpeciallyHandled((LPOVERLAPPED_COMPLETION_ROUTINE)key) && pOverlapped != NULL) { FireEtwThreadPoolIODequeue(pOverlapped, OverlappedDataObject::GetOverlappedForTracing(pOverlapped), GetClrInstanceId()); |