Real multithreading in Blazor WebAssembly

[BlenderMender]

Is your feature request related to a problem? Please describe.

I have load of CPU intensive requests connected to vial for the application data from sensors, and I would like to have a real multithreading for multiple sources which streams large amount of data nonstop.

Describe the solution you'd like

Multithreading which is available already in WEBASM to be exposed to Blazor Client side.

[mkArtakMSFT]

Thanks for contacting us, @BlenderMender.
WASM 1.0 spec doesn't include real multithreading, and this is the spec we currently target. We expect improvements in this area in the future.

[YordanYanakiev]

Wonder if the actual issue is letting JS be multithreaded and some peoples fear that this will cause some disturbance because threadings.
If this is the case I have the follow suggestion:

• Let the JS use 1 thread locked only for it - emulating the current state of the things, and the rest threads be free for background work of the C# application.

[Marcin-Perz]

I would dive deep into blazor (without any return) if there would be support for multithreading for client side. Make it happen!

[Tewr]

I've created a small library called BlazorWorker which creates a new dotnet process using web workers. It's very similar to multithreading, main difference being no shared memory, only message passing @BlenderMender @Marcin-Perz I would appreciate your feedback on the API, to see if it's a path worth pursuing in the meantime.

[mkArtakMSFT]

This is blocked on mono/mono#12453

[maxim-saplin]

Thumbs up for for proper .NET Tasks and Threads

[acceliance]

Hi, yes please make it happen. Thanks in avance.

[mkArtakMSFT]

Given the current limitations around browser support we’ve decided to push this work out of .NET 5.
We will reevaluate the state of threading support in browsers during .NET 6 planning phase.

[NikolaStamenov]

Good lords. But this is the most expected thing.
The blazor boilerplate and the way the .NET works, and the whole ideology of client side .NET project requires multithreading and real async to work correctly.
I vote to back off a bunch of other features and push for multithreading than vice-versa..

[mertkokusen]

Does this mean we will have to wait 2021 november for threading support?

[SommerEngineering]

Alright: With the current Firefox 79 the SharedArrayBuffers were reactivated. They were temporarily disabled because of Spectre. Also in Firefox 79, threads for WASM were released: https://hacks.mozilla.org/2020/07/firefox-79/ (note: SharedArrayBuffers was one prerequisite for threads in WASM)

Thus, it should be possible for .NET (Mono) to implement threadding, right?

[NikolaStamenov]

Seems like again our trust into MS Frameworks is going to be betrayed.
Blazor WebASM currently performing the worst from all available frameworks, because it's awful JS interloop and lack of multi-threading which is essential for .NET.

Please MS team - do something. Do not kill it before it's born, and do it now, December is going to be awfully late, since the disappointment will start taking space.

[SteveSandersonMS]

The vast majority of the work for this is in the dotnet/runtime repo. It will ship as a preview feature in .NET 9, which means we encourage people to try it out. In most cases it should work as you expect, though if you encounter issues we'd appreciate if you reported them.

The only part of the support that needs to be implemented in this repo is the Program.cs option that turns on serving the cross-origin-isolation headers that browsers require to enable SharedArrayBuffer (which is how multithreading is implemented). This is covered by #54062. For instructions on enabling the feature, see #54071.

Since that covers the immediately planned work in this repo, I'm going to close this issue as done. If other multithreading-related work emerges for this repo, we'll file new and smaller issues for those items.

[pavelsavara]

This is tracking progress on runtime side dotnet/runtime#85592

[mkArtakMSFT]

We've discovered additional work that is required to enable multi-threaded runtime for Blazor WebAssembly. it's tracked by #54365

This puts the overall multi-threaded runtime support work for .NET 9 at risk. We're still going to make progress towards it, but it's not clear if we will get all the issues ironed out in time.

And we will keep this issue to track the end-to-end experience.

[Eddie-Hartman]

Just trying to help in offering a potential compromise and use case in case this is a situation where the framework potentially bit off more work than it can chew to deliver in a reasonable amount of time. I feel like a lot of others are in a similar boat.

Here is the case:
I have a large C# list of objects I am displaying to a user in a grid fashion.
I have a multi-select or "process all" option.
The user clicks to process many or all of the items.
I display a MudBlazor loading spinner to indicate this may take some time to process.
I start serializing the objects to send to the server into Json. my loading spinner now freezes because of the volume of data
The serialization finishes, then server request starts and the loading spinner continues to spin.

Having read other threads about the troubles with developing this solution and persisting state properly, I'd like to propose this compromise.
The compromise:
When wanting to kick off work in another thread in Blazor WASM (in this case serializing objects to JSON), you specify the object that will change and ONLY that object's changes will be reflected when returning to the main thread. We really at minimum just want the ability to kick off some simple, yet time consuming work in the background to prevent the UI from freezing up. Limiting it to one thing in the background at a time would also work fine in this case.

If there already exists a simple and better way of doing this let me know.

[aastovas]

Just trying to help in offering a potential compromise and use case in case this is a situation where the framework potentially bit off more work than it can chew to deliver in a reasonable amount of time. I feel like a lot of others are in a similar boat.

Here is the case: I have a large C# list of objects I am displaying to a user in a grid fashion. I have a multi-select or "process all" option. The user clicks to process many or all of the items. I display a MudBlazor loading spinner to indicate this may take some time to process. I start serializing the objects to send to the server into Json. my loading spinner now freezes because of the volume of data The serialization finishes, then server request starts and the loading spinner continues to spin.

Having read other threads about the troubles with developing this solution and persisting state properly, I'd like to propose this compromise. The compromise: When wanting to kick off work in another thread in Blazor WASM (in this case serializing objects to JSON), you specify the object that will change and ONLY that object's changes will be reflected when returning to the main thread. We really at minimum just want the ability to kick off some simple, yet time consuming work in the background to prevent the UI from freezing up. Limiting it to one thing in the background at a time would also work fine in this case.

If there already exists a simple and better way of doing this let me know.

Hi Eddie, when you have a loading that is going to require much serialization, then to avoid the freeze you could use an animated gif instead of the progress bar of mudblazor. That way you can still have the animation going on... You can't though avoid the navigator prompt that at some point says the process takes too long :(

[Eddie-Hartman]

@aastovas thanks for the reply. Sorry for not being clear. I know I can use a gif, but to your point, I'd like to not lock up the UI thread and also get messages about the page not being responsive.

[mkArtakMSFT]

Hello everyone.
As some of you may have noticed, a lot of progress has been made on the multi-threading support on the .NET runtime side for WebAssembly. As we've progressed on that front, we've learned that there's still significant work to be done on the Blazor WebAssembly side to address single threaded assumptions. Given our priorities for Blazor in .NET 9 to first address quality & fundamentals (technical debt, performance, and security improvements), we've made the difficult decision to delay the remaining multi-threading related work till .NET 10.

[Eddie-Hartman]

@mkArtakMSFT While unfortunate to hear, I do understand and appreciate the other work going on in the framework. I've truly enjoyed working in this and making apps in it thus far. However, this (and better hot reload/debugging support) is something that is definitely preventing me from just broadly recommending it to people. What's been disheartening to see is how this has been pushed back over and over since .net 5: #17730 (comment)

By the time .net 10 potentially comes out and includes this, we're talking about 5 years of this. I've been following this progress since .net 6. What gives us real hope that it will come out in 10? It's been a highly requested feature. I understand there are competing priorities, but is there any level of commitment to actually seeing this through? Can we get this front and center in the roadmap?

It's hard to commit heavily to building a large production app on this framework when highly requested things like this keep getting pushed back.

I'm not saying anything is owed to us. This is a great free cross platform framework.

I just want an understanding of the impact of letting the cat out of the bag before it's ready, but teasing previews over and over is having while moving the goal posts year after year.

See again the potential compromise of something we can at least sink our teeth into in the meantime: #17730 (comment)

[Xyncgas]

I'm not saying anything is owed to us

Nothing owed, but the customers are always right in the matters of taste, ok maybe we aren't customers but we can be expressing our taste of things

[Xyncgas]

2030 technical debts are no longer a thing due to automatic software development powered by AI
Young people are going to use github in their school to learn a single button press is enough to build application for all platform from meta/natural language

[eclipsexml]

2030 technical debts are no longer a thing due to automatic software development powered by AI Young people are going to use github in their school to learn a single button press is enough to build application for all platform from meta/natural language

if you always this attitude you why blazor needs you？