Currently the UI thread is attached Mono thread and can call into Managed code.
The downside is that it needs to enter GC barrier, which makes it participate in the stop-the-world.
Current blockers are
reflection in init_managed_exports
mono_wasm_gc_lock, mono_wasm_gc_unlock used by Blazor
monoObjectAsBoolOrNullUnsafe used by Blazor
monoStringToStringUnsafe used by Blazor
mono_wasm_assembly_load, mono_wasm_assembly_find_class, mono_wasm_assembly_find_method by looking for entrypoint
GC roots in hybrid globalization
Also emscripten will complain about blocking UI thread when ASSERTIONS are enabled.
Blocking on the main thread is very dangerous, see https://emscripten.org/docs/porting/pthreads.html#blocking-on-the-main-browser-thread
Currently the UI thread is attached Mono thread and can call into Managed code. The downside is that it needs to enter GC barrier, which makes it participate in the stop-the-world.
Current blockers are
init_managed_exports
mono_wasm_gc_lock
,mono_wasm_gc_unlock
used by BlazormonoObjectAsBoolOrNullUnsafe
used by BlazormonoStringToStringUnsafe
used by Blazormono_wasm_assembly_load
,mono_wasm_assembly_find_class
,mono_wasm_assembly_find_method
by looking for entrypointAlso emscripten will complain about blocking UI thread when
ASSERTIONS
are enabled.Blocking on the main thread is very dangerous, see https://emscripten.org/docs/porting/pthreads.html#blocking-on-the-main-browser-thread
See https://github.com/emscripten-core/emscripten/blob/8c81cac1bbae378bc7dde0c21c99602cbaf452d0/src/library_pthread.js#L910-L922
If we are unable to do this, the alternative is https://github.com/dotnet/runtime/issues/76963