No Need to Wait for .NET 8 to Try Experimental WebAssembly Multithreading
Multithreading support for client-side Blazor WebAssembly apps is planned for .NET 8 in November 2023, but developers can try it out now for .NET apps thanks to experimental functionality in the brand-new .NET 7 Release Candidate 2.
Announced today, .NET 7 RC2 is production-ready code that's only one month away from General Availability.
Also today, Microsoft published a blog post explaining ASP.NET Core updates in .NET 7 Release Candidate 2. Just like in .NET 7 RC1, WebAssembly was the star of this ASP.NET Core show.
That latter item comes via a new experimental template,
In RC2, the dev team improved upon the
wasm-experimental workload now includes support for multithreaded .NET apps on WebAssembly using Web Workers," Microsoft said today. "This is a new .NET runtime capability. Multithreading support hasn't been integrated yet into Blazor WebAssembly apps (planned for .NET 8), but you can still try it out in preview form using the experimental WebAssembly Browser App template."
Other highlights of the post include:
- Output caching improvements: "Output caching was improved in .NET 7 RC2 based on preview feedback from users. In this version, output caching stores the content of the cached entries in a binary format. Previously it was using JSON. This new format is faster and smaller."
- Dynamic authentication requests with msal.js: "In .NET 7 RC1 we introduced support for making dynamic authentication requests with custom parameters in Blazor WebAssembly apps. With .NET 7 RC2, this functionality is now available when using the Microsoft Identity Platform via the built-in msal.js integration. For details on making dynamic authentication requests in Blazor WebAssembly see the Dynamic authentication requests in Blazor WebAssembly section of the .NET 7 RC1 release announcement post."
- Improved diagnostics for authentication in Blazor WebAssembly: "To help diagnose authentication issues in Blazor WebAssembly apps we added detailed logging that you can enable."
However, as the multithreading capability may be of special interest to developers, they might be advised that Microsoft posted a lengthy list of Notes and known issues with .NET multithreading on WebAssembly:
- By default, the app will create a pool of four Web Workers to execute .NET threads. To control the number of workers that are created at app startup, configure the
_WasmPThreadPoolSize property (subject to change in a future release). The maximum parallelism of your app must not exceed the worker pool size.
SynchronizationContext is used on the browser thread by default. If you do not use
ConfigureAwait(false) when awaiting asynchronous operations, they will be scheduled on the browser thread. Conversely, not using
ConfigureAwait allows your asynchronous operations to return to the browser thread in order to interact with the DOM or other JS libraries that are only available on the main thread.
- Multithreading requires that cross origin isolation is enabled by serving the COOP and COEP headers. This will restrict the functionality of the site: Enabling cross-origin isolation blocks loading cross-origin resources that you don’t explicitly opt-in, and it will prevent your top-level document from being able to communicate with popup windows.
- The build properties
WasmEnableSIMD are supported with multithreading.
JSExport only work from the main browser thread.
- WebSocket operations are only supported on the main browser thread.
- Debugging multithreaded code on WebAssembly is not yet supported.
- Threading does not work in Firefox yet due to Bugzilla #1540913.
The origin of the experimental effort comes from this GitHub issue, which notes it was completed in .NET 7 RC2 and states: "The
wasm-experimental workload supports threading using
<WasmEnableThreads>true</WasmEnableThreads> in interp [sic] and AOT configurations when using the
wasmbrowser workload. Blazor does not support threading in .NET 7."
David Ramel is an editor and writer for Converge360.