[wasm-ep] Implement EventSource counters support; add an EventPipeSessionOptions builder to TS #69567
Conversation
lambdageek
added
arch-wasm
|
Tagging subscribers to 'arch-wasm': @lewing Issue Details
|
|
@dotnet/area-system-runtime FYI, I'm making some changes to some |
- Had to set the coop GC timeout to 50 sec (might just be the recursive fib sample) - Added a method for coop GC to suspend the main browser thread in the second phase (so that other threads are less likely to deadlock if they delegate work to it) - Added an event provider builder. (TODO: make it into a builder for EventPipeSessionOptions) - Added a Thread.InternalUnsafeStart() method and a IsInternalThreadStartSupported property. This allows EventSource to start a thread to poll the counter values. - The sample with counters can now record counter values. But not at the same time as the default configuration (runtime, runtime private, sample profiler). Not sure if it's a wasm issue or a limitation of EventPipe.
it creates an entire EventPipeSessionOptions object, not just the providers config
lambdageek
force-pushed
the
wasm-ep-counter
branch
from
e349029 to
b5b7a3f
Compare
lambdageek
requested review from
vargaz,
lateralusX and
marek-safar
as code owners
|
@lateralusX @pavelsavara Can I get a review for this PR, please |
| internal static bool IsThreadStartSupported => true; | ||
| internal static bool IsInternalThreadStartSupported => true; | ||
| #elif FEATURE_WASM_PERFTRACING |
There was a problem hiding this comment.
Does this have any relationship with the wider, FEATURE_PERFTRACING used to guard all perftracing support?
There was a problem hiding this comment.
I think FEATURE_PERFTRACING can be true or false on the wasm threaded runtime, ie it's the general perftracing support. Whereas FEATURE_WASM_PERFTRACING is the specific configuration where user threading is disabled.
There was a problem hiding this comment.
Yes, FEATURE_PERFTRACING will turn on/off all diagnostics supports, both in BCL and runtime. So can you build EventPipe/Diagnostic support on WASM without user threading enabled and get something to work and would you enabled FEATURE_WASM_PERFTRACING without enabling FEATURE_PERFTRACING?
There was a problem hiding this comment.
maybe I should rename FEATURE_WASM_PERFTRACING to FEATURE_WASM_INTERNAL_THREADS_ONLY or something. The point is that it enables starting utility threads, but doesn't enable general user threading.
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-wasm |
|
Azure Pipelines successfully started running 1 pipeline(s). |
ghost
locked as resolved and limited conversation to collaborators
Important change adds
Thread.IsInternalThreadStartSupportedandThread.InternalUnsafeStart()toSystem.Threading.Threadthat can be used by System.Private.CoreLib to start threads on a runtime whereThread.IsThreadStartSupportedis false.This is used to create the event counters polling thread.
This is in addition to the native runtime being able to create threads using
mono_thread_create_internalmono_threads_platform_stw_defer_initial_suspendwhich postpones suspending a thread until the next GC suspend phase. Doesn't do anything on most platforms. On WASM, suspend the main browser thread after all the other threads are suspended. This helps prevent deadlocks where the main thread is suspended while another thread is doing a call that is proxied to the main thread and cannot complete. By suspending the main thread last, we give it a chance to service the other threads' requests.MONO.diagnostics.SessionOptionsBuilderclass that can be used to create anEventPipeSessionOptionsinstance and populate the provider string for an event pipe session.browser-eventpipesample to create an EventSource and some counters. The sample is now interactive so you have to click "Start Work" in a browser for things to happen.There's an outstanding issue #69568 that will be investigated in a follow-up PR