aspnetcore
aspnetcore copied to clipboard
dotnet
Real multithreading in Blazor WebAssembly
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.
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.
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.
I would dive deep into blazor (without any return) if there would be support for multithreading for client side. Make it happen!
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.
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.
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..
Does this mean we will have to wait 2021 november for threading support?
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?
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.
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
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..
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.
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.
Additional customer requests here: https://github.com/dotnet/runtime/issues/40619
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.
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..
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.
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.
Agree with @RChrisCoble - hope this is considered for inclusion soon. Looks like Safari has enabled it via a preview flag.
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.
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?
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.
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.
@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 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.