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 https://github.com/mono/mono/issues/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.

[acceliance]

Ok for the previous comment but, does the underlying framework actually support for threading ? Because you know if not, this very discussion thread would be meaningless (i hope not of course)

Thank you for answering

[YordanYanakiev]

Blazor is on top of Mono, Mono is on top of WebAsm. WebASM does support multithreading, Mono does support multithreading - but the implementation lack atm I believe for Mono because.. idk..

[acceliance]

Sounds great so the path is open for .net blazor :-)

[Henk7]

It would be good if there was a documentation article regarding the current state of multi threading in blazor wasm. Reading issues on github doesn't always give a good sense if things are still current. Also, a "good to know" article about common pitfalls regarding the current single thread environment of blazor wasm. What's the Behavior of a "Thread.Sleep" or a "ManualResetEvent.WaitOne" ect. I just dropped an old library of mine into blazor wasm and I had to hunt down those things.

[ghost]

Thanks for contacting us. We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[danroth27]

Additional customer requests here: https://github.com/dotnet/runtime/issues/40619

[danroth27]

Current state of browser support for shared array buffers, which is required to support multithreading: https://caniuse.com/?search=sharedarraybuffer. Still not supported in Safari on desktop or on mobile. Mobile support in general is largely missing. Reasonable desktop support with Edge, Chrome, and Firefox.

[YordanYanakiev]

Emh.. actually they all does support it, but it is disabled due Meltdown ( 2018 ). The state of the vulnerability should be checked and patched by the OS providers maybe..

[RChrisCoble]

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.

Hopefully this re-evaluation can happen again as support of threads would be a powerful feature for Blazor in the client. Opens up a whole new category of scale for apps in Blazor.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Agree with @RChrisCoble - hope this is considered for inclusion soon. Looks like Safari has enabled it via a preview flag.

[RChrisCoble]

Agree with @RChrisCoble - hope this is considered for inclusion soon. Looks like Safari has enabled it via a preview flag.

It's not in the plan for .Net 6, so looks like we're waiting for .Net 7.

[andersson09]

Agree with @RChrisCoble - hope this is considered for inclusion soon. Looks like Safari has enabled it via a preview flag.

It's not in the plan for .Net 6, so looks like we're waiting for .Net 7.

Do we have anything that says it is officially in the .NET 7 roadmap?

[Marcin-Perz]

:(

[RChrisCoble]

Agree with @RChrisCoble - hope this is considered for inclusion soon. Looks like Safari has enabled it via a preview flag.

It's not in the plan for .Net 6, so looks like we're waiting for .Net 7.

Do we have anything that says it is officially in the .NET 7 roadmap?

Well, publicly nothing is 'officially' in scope for .Net 7. I'm sure MS has their own internal multi-year .Net roadmaps, but we would need to wait for the conclusion of their .Net 7 release planning in 2022 Q1 before knowing for sure.

In .Net 6 they are investing in "Blazor Desktop" tooling, which is fantastic, but if you're using any task based parallelism wherein you are doing a .Wait() or .Result waiting for a task(s), that code will work in the Blazor Desktop model but not the web. This is a little weird from my standpoint, so I hope they enable the task based parallelism in Blazor Client topologies so you don't have to deal with this nuance. Sure there are workarounds like building a custom task scheduler, but from a QA standpoint it really would be handy to have a single code base, which is the ultimate vision of Blazor/MBB/MAUI.

[YordanYanakiev]

In my arrogant opinion - this should be investigated as a side project which actually can wait, since desktop aps for sure will not go web anytime soon. Actually the opposite - most of developers I know stick with even tools like C++ Builder because performance, stability, and look, and they are absolutely sure that none desktop app based on web core will go any further than "hello world" on their company project list anytime soon. Blazor is loosing momentum going sideways instead of fixing absolutely important issues and adding very important features which is from long time in the Web dev's lists. And hell - since when the opinion of Apple mater for Microsoft ?! But as I have said - this is just me and my arrogant opinion.

[Cryru]

@RChrisCoble I don't want to derail the conversation, but could you provide some more information for working around it with a custom task scheduler? Code references, or an article or something? Thanks ^^

[RChrisCoble]

@RChrisCoble I don't want to derail the conversation, but could you provide some more information for working around it with a custom task scheduler? Code references, or an article or something? Thanks ^^

My suggestion is somewhat theoretical, but plug those words into Google and you can find samples. The idea is you derive from TaskScheduler and instead of leveraging the thread pool you execute the tasks on the current thread, as there is only 1 thread in Blazor Client.

In a perfect world, you can just modify your code to use async/await everywhere, which doesn't hang in Blazor client with the understanding that it's also not running in parallel.

[anthony-c-martin]

@RChrisCoble I don't want to derail the conversation, but could you provide some more information for working around it with a custom task scheduler? Code references, or an article or something? Thanks ^^

My suggestion is somewhat theoretical, but plug those words into Google and you can find samples. The idea is you derive from TaskScheduler and instead of leveraging the thread pool you execute the tasks on the current thread, as there is only 1 thread in Blazor Client.

In a perfect world, you can just modify your code to use async/await everywhere, which doesn't hang in Blazor client with the understanding that it's also not running in parallel.

This is fine for light async processing, but if you want to do anything compute-intensive, you're going to end up blocking the UI thread, which will cause the UI to feel jerky and unresponsive.

[IvanIvanyuk]

@RChrisCoble I don't want to derail the conversation, but could you provide some more information for working around it with a custom task scheduler? Code references, or an article or something? Thanks ^^

If you are familiar with Rx, I think the easiest way to use custom schedulers is to use System.Reactive and IScheduler. Out of the box, it provides some common schedulers like ThreadPoolScheduler, EventLoopScheduler, NewThreadScheduler etc.

[teo-tsirpanis]

To add my use case, I am writing an app that performs single-threaded work that might take time. I want this work to be performed while the user is typing their input to the app's input text area without being blocked. I also want to cancel it with a button that triggers a CancellationToken. Using a backend is unfortunately not an option (I want it to work offline and minimize operating costs).

My existing approach is using @Tewr's library to create a background web worker that performs the work and returns its result. When the CancellationToken is triggered, the web worker is forcefully terminated and restarted. There are actually two interchangeable web workers to lessen the overhead of cancellations, one active and another one in standby.

This approach is error-prone and has an overhead akin to creating a new process and exchanging serialized data with it. Adding actual threads to Blazor WebAssembly would solve the problem with a surprisingly simple solution and no serialization overhead.

[ElanHasson]

I had thought of making a TaskScheduler to wrap @Tewr's library. Yes it'd be slow-er than real threads, but I considered modifying the bootstrap Js to wrap fetch and use cache like blazor does. Also, using an LRU object pool for each IWorker type and keeping them warm.

This would mean channels, TPL would work.

Another idea I had was patching fetch to optionally use an IWorker from the pool as well. This would mean all HttpClient calls would be run in a worker. large responses would bypass message serialization by using Local storage or IndexedDb or app Cache and the response would be a pointer.

[Xyncgas]

In my arrogant opinion - this should be investigated as a side project which actually can wait, since desktop aps for sure will not go web anytime soon. Actually the opposite - most of developers I know stick with even tools like C++ Builder because performance, stability, and look, and they are absolutely sure that none desktop app based on web core will go any further than "hello world" on their company project list anytime soon. Blazor is loosing momentum going sideways instead of fixing absolutely important issues and adding very important features which is from long time in the Web dev's lists. And hell - since when the opinion of Apple mater for Microsoft ?! But as I have said - this is just me and my arrogant opinion.

I am just a no body but I kinda want to see your list of 'important features' and I think it can leave a note to the developers

[RChrisCoble]

@danroth27, @SteveSandersonMS.

In the planning for .Net 7, supporting this behavior is my biggest request. In the larger vision of having a single code base and UI layer that supports Windows, Mac, iOS, Android, etc. using Blazor, having to tailor your existing C# "massively parallel" Task based code to accommodate Blazor WebAssembly is challenging.

As an aside from a PgM perspective, I believe supporting this will be a huge win over other web frameworks and make Blazor even more compelling than it already is.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[dt200r]

To parrot others, this is also our biggest desire for .net 7. We have done some prototyping with the current Blazor but without true multithreading the performance is simply inadequate. We have written highly concurrent client libraries in C# that we would love to use in the wasm environment.

[Xyncgas]

Why can't we just use all the threads all the times? it doesn't have to be crazy loaded. but if we are just executing things there's no reason our computer can't be smart enough to put them across all the cpu available. there is one problem which people concerned being racing issues and what it truly is, is a dependency issues that we can solve because we have these concepts available at compile time already. so let's make codes run at all cores automatically when running on .NET, unless explictly told not to in the source

[YordanYanakiev]

I start to fear that Blazor will follow Flash, which was multiple times delayed from it's actual possibilities, and then opposed by Apple, because their devices couldnt execute proper multithreading, and on top of that there were super cool aps which were going into their devices for free, and Microsoft plain give up on their small treasure called "Flash" because no actusl reason. The same start to look the situation with WEBASM.

[andersson09]

@mkArtakMSFT What steps are needed from Microsoft's side? Has anyone tried compiling mono by passing the -pthread flag into the emscripten compiler?

Might give this a go if no one else hasn't.

[hoangdovan]

@YordanYanakiev Apple Safari now become "new IE" with super slow new features implementation. But because web assembly is standard of web, the story is surely different to Flash. Both Apple & MS will follow and implement web standard in their product. It's just a matter of time...

[hoangdovan]

@dt200r Hey, it's same for me. Temporarily while waiting for this feature. My work around: using web worker with JavaScript interop unmarshall calling. It's not really good, but get the job done.

[Xyncgas]

I am starting to feel like web-browser should just be a docker with pretty UI. Btw how long are we going to wait for Web-assembly to implement threads? Whenever we are trying to do something we are always burdened by the restrains of various technology venders we are relying on, the surface area of just the client side of the of the web is too big. Then the back end is fine because everything gets turned into 0 and 1 through the cable anyways. Just kill webassembly at this point it's already been years since their last release

[Xyncgas]

This is the state of modern applications btw, everything is running on top of something, blocked by the delay of implementations of features in the underlying platform, when the good old days you just give people your app, and it runs as long they have a cpu that the program was compiled for.

I am hoping, since people are running windows, let's have a single browser that's in the operating system, there will be no chromes on windows, unless they interface it with the OS's browser, then we can do crazy things like run any code in any language targetting this browser, which runs on .NET, which then expose pretty UI letting people maybe design it using html & css, but also allowing c# to manipulate UI like xamarin, it's going to be a major platform that evolves along with .NET, providing many benifit and the freedom to make features available, without worrying about what browsers your users have. if they run windows they can visit your website.

this technology can be duo-cored, one that still use chromium for legacy websites and one for new-compiled-websites, and when you put the word legacy out there websites that pretend this isn't a thing will die out fast

[Xyncgas]

https://github.com/dotnet/aspnetcore/issues/38745

[Cpt-Falcon]

Multi threading should be supported on chrome based browsers. Multi threading should be implemented in terms of the task pool and scheduler. Then if running on an unsupported browser the task pool is configured so that it only has access to one real thread. Then all logic written will work on a single threaded browser, but will receive a serious uplift in performance when running on chrome and N threads are available for the task pool to utilize.

Are there any updates on multi threading for blazor wasm? ALso don't give me that nonsense that threads aren't supported in web assembly, take a gander:

https://web.dev/webassembly-threads/

In summary web assembly supports mutli threading, chrome based browsers support multi threading, and you could reasonably develop a multi threading system in blazor wasm using the task pool. Anything that relies on Task.run would then benefit greatly.

[Xyncgas]

Multi threading should be supported on chrome based browsers. Multi threading should be implemented in terms of the task pool and scheduler. Then if running on an unsupported browser the task pool is configured so that it only has access to one real thread. Then all logic written will work on a single threaded browser, but will receive a serious uplift in performance when running on chrome and N threads are available for the task pool to utilize.

Are there any updates on multi threading for blazor wasm? ALso don't give me that nonsense that threads aren't supported in web assembly, take a gander:

https://web.dev/webassembly-threads/

In summary web assembly supports mutli threading, chrome based browsers support multi threading, and you could reasonably develop a multi threading system in blazor wasm using the task pool. Anything that relies on Task.run would then benefit greatly.

Or abandon blazor-wasm today for MAUI-blazor

[RChrisCoble]

@Xyncgas: Or abandon blazor-wasm today for MAUI-blazor

For my Use Cases, both are required which is what makes Blazor so attractive. Customers need rich SaaS experiences through a browser? Blazor. Customers need a fast native mobile experience? Same Blazor app wrapped in MAUI. Need to augment legacy OnPrem tooling with new editors that you also need in SaaS? MAUI-Blazor or WPF-Balzor.

I started coding before the web existed. In all the web years, it was like, "Ok, we're building a desktop app, we can use technologies x, y, z", compared to a, "We're building a web app, we can only use technologies p, d, q", or, We're building a mobile app, we need something different that the prior 2. There's just not enough money or developers to satisfy those three and deliver fast with quality. (when the rubber meets the budget road).

With Blazor, write once and basically use everywhere. True multi-threading support seals the deal.

[chingham]

This is really needed for Blazor. In our case, the main purpose of Blazor is to be able to add another UI layer (web) on top of portable libraries for which we already have Windows, iOS and Android UI layers

Our company's C# libraries all relie heavily on Tasks and multi-threading, and by reading the comments here, I believe we're not the only ones

For us, this feature is definitely on the top 3 for Blazor !