[tracking] Experimental WebAssembly multithreading support #68162
Comments
lambdageek
added
arch-wasm
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsThis is a tracking issue for adding experimental support for WebAssembly multi-threading to the browser-wasm runtime pack. On the branch:
Experimental support in
EventPipe in
Issues:
Ecosystem:
|
dotnet-issue-labeler
bot
added
the
untriaged
Merge initial work on multi-threaded WebAssembly.
The normal wasm build is single-threaded. There should be no functional changes to its behavior.
To enable a multi-threaded build pass `/p:WasmEnableThreads=true`. See `src/mono/wasm/threads.md` for details.
The big changes are:
1. The normal ref assemblies related to threading retain `[UnsupportedOSPlatform("browser")]` attributes for various threading-related functions
2. In System.Private.CoreLib, the `[UnsupportedOSPlatform]` attributes are removed, and functions that used to always throw PNSE nwo do a runtime check using `System.Threading.Thread.IsThreadStartSupported` to check if threading is enabled in the current build.
3. A new nuget `Microsoft.NET.WebAssembly.Threading` is created. It contains experimental ref assemblies without the `[UnsupportedOSPlatform]` attributes. The intention is that code opting into experimenting with multithreading will include this nuget by setting some property that will be used by the wasm MSBuild SDK to pick a multi-threaded runtime build and configure things appropriately. (The SDK updates don't exist yet).
4. In the multi-threaded runtime we don't use Emscripten's "main thread" option (ie: the browser thread is the main one); we also continue to run certain runtime-internal jobs (finalizers, GC pump) on the main thread even in the multi-threaded runtime.
Remaining work is tracked in the related issue #68162
---
* Initial changes for emscripten 2.0.34
* Use emcc-link.rsp in build targets
* Use updated docker images
* Fix compiler warnings
* Put `--profiling-funcs` to `_EmccLinkFlags`
* Fix build
src/mono/mono/mini/mini-runtime.c:3407:25: error: ‘invoke’ undeclared (first use in this function); did you mean ‘revoke’?
3407 | invoke = mono_marshal_get_runtime_invoke_dynamic ();
* Add shell to the environment
Environment setting https://github.com/emscripten-core/emscripten/blob/2.0.34/src/settings.js#L616-L641
From emscripten 2.0.25 release notes
- Support for the 'shell' environment is now disabled by default. Running under
`d8`, `js`, or `jsc` is not something that most emscripten users ever want to
do, so including the support code is, more often than not, unnecessary. Users
who want shell support can enable it by including 'shell' in `-s ENVIRONMENT`
(#14535).
Example of the the size increase for bench sample:
-a--- 12/10/2021 3:35 PM 382113 dotnet.js
-a--- 12/13/2021 10:37 AM 383589 dotnet.js
* Add emcc-link.rsp to PlatformManifestFileEntry
* Feedback
https://github.com/emscripten-core/emscripten/blob/2fda25eea756c78c8cb024aa5b6c2b188bf7990f/src/settings.js#L1173-L1176
-s EXPORT_ES6 is link option
* Bump emscripten version
* Bump llvm package version and use its libclang
* Use newer docker images with emscripten 3.1.1
* Remove unused variable
* Add runtime support for threads in the wasm build
To enable, pass `/p:WasmEnableThreads` when building the runtime
./build.sh -Subset mono+libs -os Browser -arch wasm /p:WasmEnableThreads=true
* Prevent runtime from starting twice when loaded in a web worker
* Automatically populate the emscripten mainScriptUrlOrBlob property so that worker initialization can find dotnet.js
* Add compatibility shim so that emscripten's generated worker.js can properly get a Module instance, since we broke the API
* Checkpoint
* Bring back threadpool and add some tracing in diagnostics
* Add comments and fix a typo
* Introduce 'MonoObjectRef' ts type. Migrate mono_string_intern to not have a retval
* Checkpoint (strings are broken for some reason)
* Fix string interning
* Migrate ObjectToString and GetDateValue
* Checkpoint gc safe/unsafe region work
* More ref conversion
* Checkpoint (broken?)
* Fix missing method
* Fix incorrect signatures
* Fix lint
* Add new 'R' signature char for 'ref object'
* Remove AddEventListener and RemoveEventListener Checkpoint
* eslint fixes
* Update call_method signature to avoid passing raw object pointers
* Ref-ify one websocket API and fix types and incorrect rooting of two others
* Deprecation metadata
* More ref
* Remove outdated comments
* Convert typed_array_new to ref
* Add volatile modifiers, satisfy eslint
* Update src/mono/wasm/runtime/corebindings.c
* Missing conflict
* Fix build, set coop gc, and always copy dotnet.worker.js when it's around for apps
* Disable sample profiler, add some functions that were missing from katelyn's PR.
* Add safepoint around ep_rt_wait_event_set. Tweak sample to explicitly exit wasm in order to properly flush event to the nettrace file (w/ rundown events).
* [gc] Start the GC Finalizer thread on threaded WASM
* [mono] add GC Unsafe in mono_assembly_load; remove in EventPipe
Remove GC Unsafe hack in ep_rt_wait_event_set
* post-merge cleanup: delete duplicated definitions
* [sample] Env vars should be stringy
* updated dotnet.d.ts
* Add mono_threads_wasm_async_run_in_main_thread; do background work on main
Don't start a finalizer thread
Queue all background work to run on the main thread
* [mono] Fix non-threaded wasm build
* Add a System.Threading.Thread.WebAssembly.Threading ref assembly
* Update the browser sample to use System.Threading.Thread.WebAssembly.Threading
* Rationalize System.Threading.Thread build
In CoreLib, never add the [UnsupportedOSPlatform("browser")] attribute. Rely on runtime checks (`ThrowIfNoThreadStart()`). In System.Threading.Thread ref assembly, always add the unsupported platform
attribute. Add mismatches to ApiCompat baseline. In System.Threading.Thread.WebAssembly.Threading don't add the attributes, and also set DisablePackageBaselineValidation to prevent Restore from looking for a System.Threading.Thread.WebAssembly.Threading nuget (fixes in-tree ProjectReferences for testing)
* only turn on analyzers for the browser sample
not all wasm samples
* Make a single Microsoft.NET.WebAssembly.Threading nupkg
that holds all the special ref assemblies
* works: sample has ProjectReference to the Microsoft.NET.WebAssembly.Threading.proj
* Add System.Threading.ThreadPool.WebAssembly.Threading ref assembly
* ThreadPool: throw PNSE if no thread start
* Update wasm threads.md
* apicompat: correct warnings for System.Threading.ThreadPool
* Add dotnet.worker.js to the runtime pack; update PlatformManifestFileEntry
* [wasm] startup: detect Blazor dotnet.[version].[hash].js location
Blazor injects a `<link rel="modulepreload" />` element into the header when it boots; detect it and extract the URL of the script.
This is needed by Emscripten's dotnet.worker.js to run WorkerGlobalScope.importScripts
* one more fix to Microsoft.NET.WebAssembly.Threading
Seems to be necessary in order for the resulting .nupkg not to reference non-existent nugets for the ProjectReferences
* rename sample to browser-mt-eventpipe
* bring back unmodified browser sample
The multithreading sample is browser-mt-eventpipe
* update browser-mt-eventpipe sample to use ref assembly refs
Referencing the rollup Microsoft.NET.WebAssembly.Threading.proj doesn't work (it ends up bundling the ref assemblies into the publish dir and breaking the app)
* Use correct ifdef in AppContext.AnyOS.cs
* [build] support WasmEnableThreads and WasmEnablePerfTracing
These toplevel options either turn on multi-threading in general, or turn on multithreading only for eventpipe internals.
For libraries these define `FeatureWasmThreads` and `FeatureWasmPerfTracing` properties and the `FEATURE_WASM_THREADS` and `FEATURE_WASM_PERFTRACING` compiler constants.
For the native code, they control `DISABLE_THREADS` and `DISABLE_WASM_USER_THREADS` cmake and preprocessor settings.
* Only add the portable threadpool on wasm if threading is enabled
* rename browser-mt-eventpipe csproj and main assembly
Give it a unique name distinct from Wasm.Browser.CJS.Sample.csproj
* fix /p:WasmEnableThreads=false build after merge
* now fix the WasmEnableThreads=true build
* we need two ThreadPoolBoundHandle implementation stubs
one for PortableThreadPool when threads are enabled, one for single-threaded wasm
* Add a System.Diagnostics.Tracing ref assembly gated by FeatureWasmPerfTracing
* [eventpipe] use the correct cmake option name
see src/mono/mono.proj
* revert debug printf and commented out code
* turn off additional logging
* hack: set FeatureWasmPerfTracing in the browser-mt-eventpipe sample
It would be better to drive this (the inclusion of the tracing runtime component) from a user-visible flag. not the FeatureWasmPerfTracing implementation detail
* remove unused variable, remove unneeded configure checks, revert line damage; add better comment in export.ts
* Exclude Microsoft.NET.WebAssembly.Threading from testPackages.proj
* review feedback, Apply suggestions from code review
* Use a testPackages settings file to skip package runtime item verification
* remove unneeded Directory.Build.props for ref package
since ti doesn't compile its own assembly, none of these properties are needed
* use one ProjectReference item to share metadata for the ref assemblies
* remove ProjectReference comment and NoTargetsDoNotReferenceOutputAssemblies prop
* Remove unneeded target
* packaging simplification
- move `_ExperimentalUpdateFileVersion` target to packaging.targets, conditioned on a new `IsExperimentalRefAssembly` attribute. (The target increments the file version of the ref assembly to make it easier to distinguish from the real non-experimental ref assembly)
- Remove unneeded src subdirectories in ref assembly libraries
- Move properties that are only used in the ref assembly projects directory into the projects and delete Directory.Build.props in the experimental ref assembly subdirectories.
* move and rename UpdateExperimentalRefAssemblyFileVersion target
packages.targets is only included for IsPackable=true projects, and these ref assemblies are not packable.
* Assorted code review nits
* Don't build/pack the multi-threaded sample on single-threaded runtime
* remove gratuitous debug printfs
* Apply suggestions from code review
* merge followup: nullable is enabled by default now
* make eslint happy
* include wasm-config.h in wasm runtime host
* include wasm-config.h into the runtime pack
fixes aot compilation
* Add wasm-config.h to manifest
* put wasm-config.h into include/wasm from the outset
* put back noExitRuntime replacement for CJS
Co-authored-by: Radek Doulik <radekdoulik@gmail.com>
Co-authored-by: Radek Doulik <radekdoulik@google.com>
Co-authored-by: Zoltan Varga <vargaz@gmail.com>
Co-authored-by: Steve Pfister <steve.pfister@microsoft.com>
Co-authored-by: Katelyn Gadd <kg@luminance.org>
Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
|
Ooh, just came to check in on how things were going on the mono wasm side of this and came across this tracking issue. Nice to see this being tracked on the dotnet/runtime side now. It's good to see that the browser-wasm RID was the final answer on that particular design challenge, but I remember how much discussion there was about trying to avoid adding additional runtimes unnecessarily. Trying to make sense of the current state of these tickets, are we expecting that the browser-wasm runtime will be multi-purpose and have some convention for choosing subtypes, rather than defining new RIDs for multi-threaded and perf-trace package variants? Part of me feels like the multi-thread variant would be better served by its own RID if there are plans to support both (fundamentally different) runtimes for any extended period (e.g. reference assemblies/contracts can expose different supported surface areas at compile time rather than throwing runtime exceptions). Is there a sense of how this will work for packaging and compile MSBuild conditions? It seems like WasmEnableThreads is rather narrow and probably only impacts the application build, not so much for libraries, NuGet packaging, etc. unless the desired result is for the compiler to be able to generate all variants automatically, but it seems like there would be significant design implications there, where performance and a variety of other factors would want to be able to provide different implementations for the different environments (e.g. concurrency-safe collection types could ignore concurrency without MT but might need to leverage platform-specific no-lock behaviors, etc.) Understandable if these aren't answered yet, just trying to get a sense of how these things intend to be differentiated by component developers between the runtime and consuming developers. I ask here mainly because it seems there are multiple possible threads that seem appropriate. Feel free to move this comment or direct me where best to move the discussion. Otherwise, glad to see there's already some experimental support running now. |
|
what happend if this feature not support with browser? |
|
How, if any, effect for this have on Task based threading? If one creates multiple HttpClient.GetAsync tasks and schedules them using Task.WhenAll, will all tasks run in parallel on their own threads? Does each task need the ConfigureAwait(false) to be set? If that is the case and you are sharing this code between Blazor WASM and Blazor Hybrid, are there any repercussions in MAUI by doing that? |
|
Threading allows tasks to run on multiple threads, yes. Things that interact with browser APIs like HTTP are a more complex scenario, because browser APIs have thread affinity (think the nightmare of COM apartments, but worse) |
|
The Blazor needs to provide dotnet.worker.js as a js-module-threads asset list item probably needs its own issue for the following reasons:
The error message for visibility Trying to poke around by finding dotnet.worker.js and copying it with the right name doesn't seem to be any use as the referencing code really expects it to be part of the bundle. |
Have you found a tmp solution? |
|
I haven't, I was expecting the team here to revert with a workaround or a fix. I believe the key is hardcoded and I wasn't able to find extensibility points to impact the bundling process. |
|
Any update on the |
That's exactly right. It's not supported yet, but I'm working on it. I'm curious to know more about your use case. Note that with #84489, only threads started with Just starting a thread with |
I have an app I'm trying to port, which calls a blocking function in a non-managed dll: To port it to WASM/JS it instead needs to call an async JS function (ignore that it no longer takes any arguments): I've made an interface that lets me link to either the DLL or the JSImport, but I just need some way to block while I wait for the promise to resolve. And that's pretty much it! (I also tried making the app async, but it's a messy legacy app and I would end up needing convert nearly everything to async functions, so threads seems a better option.) (And async functions not having |
Any news on this? I'm still seeing this today, not sure how to work around it. |
Unfortunately Blazor support for threading is taking a bit longer than we would have liked. We're working on it, but it's not something that you can experiment with at this point. We do expect to have something in a later .NET 8 preview. |
Thats a shame, thank you for your reply 😊 |
pavelsavara
added
area-VM-threading-mono
os-browser
|
I updated MT tracking issue #85592 |
|
hello, Anyone know if this meta tracker could updated for net8 ? now that the release is done ?
|
There were mostly low level steps toward multi-threading during Net8, but it's not supported in Net8. |
Ah cool, thx a lot for the next release tracker :) 
This image is why I asked, Now i understand that there's another one regarding Net9.0 The question is ... from an outsider point of you it would be nice to have this issue either
I'm not trying to be picky, I'm just hardly able to try to follow up cross release "Epic size" feature when there's a lot of cross over that are not listed. |
This is a tracking issue for adding experimental support for WebAssembly multi-threading to the browser-wasm runtime pack.
High Level Goals
The threading runtime should be distributed in the same browser-wasm runtime packThe threading runtime is in a separate.multithread.runtime pack variant. The WASM SDK chooses the correct runtime pack variant based on project properties.Completed in .NET 7 RC2
The
wasm-experimentalworkload supports threading using<WasmEnableThreads>true</WasmEnableThreads>in interp and AOT configurations when using thewasmbrowserworkload. Blazor does not support threading in .NET 7Tracking
SDK:
dotnet-counters/dotnet-trace(viadotnet-dsrouter)CI testing:
ProjectReferences to the multi-threaded ref assemblies (the roll-upMicrosoft.NET.WebAssembly.Threading.projdoesn't seem to work) and run the normal runtime tests.Libraries and Interop:
dotnet.worker.jsas ajs-module-threadsasset (fixed by [browser] Enable threads in Wasm SDK #85109)Diagnostics:
[wasm] [debugger] First version of multithreaded debugging #74820
epsubfolder in the runtime packepartifacts if a property is set.Runtime and codegen:
Issues:
Microsoft.AspNetCore.Components.WebAssembly.DevServer(used by blazorwasm fordotnet run) should serve CORS headersdotnet.worker.jsthat usesevalandrequire[wasm] proper startup sequence indotnet.worker.js#70891Thread.Start().Waitpattern on the browser threads will deadlock. Emscripten relies on the browser thread's eventloop to start threads (unless we use a dedicated "main" thread when building). After a thread start, the browser thread's eventloop must run in order for new threads to start.Done
On the branch:
/p:WasmEnableThreads=trueFeatureWasmThreadsin project files andFEATURE_WASM_THREADSin C# code to conditionally include[UnsupportedOSPlatform("browser")]guards around multi-threading APIs, and include the ref assembly inMicrosoft.NET.WebAssembly.ThreadingFeatureWasmThreadsandFEATURE_WASM_THREADSto defineSystem.Thread.IsThreadStartSupported. All other code should checkSystem.Thread.IsThreadStartSupportedto throw a PNSE. There should not be[UnsupportedOSPlatform("browser")]guards in CoreLibFeatureWasmPerfTracingandFEATURE_WASM_PERFTRACING(and a constant?).browser-mtandbrowser-mt-eventpipesamples.mainIn .NET 7 RC2
Build and package:
browser-wasmruntime pack should pack both single- and multi-threaded builds. #68508 completed as part of Add support for building WASM variants alongside single-threaded to the build system #71054Microsoft.NET.WebAssembly.Threading.nupkgref assemblies package should be published to the dotnet7 feedLibraries and interop:
Need a hook for frameworks to identify the location ofWe set up an asset loading framework that handles these use cases [wasm] asset loading for workers #73484dotnet.js. Emscripten relies onmainScriptUrlOrBlobproperty on the module on the main threads to be set to the URL ofdotnet.jsso that it can locatedotnet.worker.js. Frameworks like Blazor sometimes renamedotnet.jsand/or move the wasm artifacts into subdirectories. Provide a hook for them to tell the runtime where to find the files.AOT
MONO_THREADS_SUSPEND=coopmono-aot-cross environment setting) [mono][wasm] Add a 'wasm-gc-safepoints' option to enable the generati… #70520mono-aot-crossthat doesn't emit safepoints for single-threaded wasm, but does emit safepoints for mt) [mono][wasm] Add a 'wasm-gc-safepoints' option to enable the generati… #70520CI testing:
In .NET 8
...
The text was updated successfully, but these errors were encountered: