What will happen if C# p/invokes a C++ WASM module that starts a WebWorker and then calls back to C# callback?

[devshgraphicsprogramming]

Summary

Since SharedByteArray is again available on browsers (provided you do all the CORS header stuff properly as required by site isolation), this renders the following comment https://github.com/dotnet/aspnetcore/issues/16954#issuecomment-552226873 obsolete.

Also AFAIK, WebWorker post-message (exposed as a C API in emscripten) does not need SBA to work, but yes, without SBA attempting to work on the same memory will straight up not work.

Anyway, realizing that Blazor wont catch up on SBA availability immediately, I've had an idea (assuming #56145 doesn't prevent me) to use a small C++ lib to facilitate launching or additional threads or web workers executing C# code.

Now the question is, will that break the runtime?

Motivation and goals

Achieve threading or parallelism while still running C# and not C++

In scope

• Running single threads of C# code invoked from a Emscripten Pthreads/WebWorkers.
• P/invoking post-message between workers
• newing C# objects in multiple threads which won't share objects

Out of scope

• Simultaneous use of a GC/Managed C# object from multiple threads
• atomics
• using C# parallelism/threading primitives, like its thread/coroutine/task API, mutexes, etc

Risks / unknowns

1. Will the VM or runtime (AOT) just crash or throw a fit from being called into by multiple threads (is your stack, etc threadlocal)
2. Will the runtime's Garbage Collector corrupt or leak due to threading (i.e. you assume stop-the-world during a yield from main UI thread and eveything will be UB if memory is being touched from other threads during the GC run)
3. Will the memory allocator (part of GC I guess) corrupt because it has no implementation of, r doesn't use a mutex under WASM?

Bonus Round

Is it possible to make the Blazor runtime back its GC arena/memory-pool with WebAssembly.Memory(,,shared:true) ?

Related

14253

[javiercn]

@devshgraphicsprogramming thanks for contacting us.

This is a dupe of https://github.com/dotnet/aspnetcore/issues/17730

[devshgraphicsprogramming]

@devshgraphicsprogramming thanks for contacting us.

This is a dupe of #17730

I didn't get answers to any of my questions.

[Xyncgas]

Nowadays .NET runs in either Webassembly or native with blazor projects (E.G Blazor Webassembly vs Maui.Blazor)

The awesome firefox cartoon girl Lin Clark said there is a wasm land and JS land, if you are calling .NET codes running in webassembly it might work especially if a worker thread can access resources in other threads / worker I guess.

I am more confident that it would work if .NET is running without Webassembly, I have never tried it though

[janseris]

Nowadays .NET runs in either Webassembly or native with blazor projects (E.G Blazor Webassembly vs Maui.Blazor)

The awesome firefox cartoon girl Lin Clark said there is a wasm land and JS land, if you are calling .NET codes running in webassembly it might work especially if a worker thread can access resources in other threads / worker I guess.

I am more confident that it would work if .NET is running without Webassembly, I have never tried it though

How do you mean native when MAUI Blazor just uses Javascript?

<script src="_framework/blazor.webview.js"></script>

There was a native Blazor project called Blazor Mobile Bindings which was scrapped. That project focused on binding native (platform specific) controls to Blazor syntax. Before Blazor was added to MAUI, it was called Blazor Desktop. Today it is called Blazor Hybrid which causes confusion with the project "Blazor Mobile Bindings".

[Xyncgas]

Dotnet rt doesn't run inside Maui.Blazor's webview I found out, all your c# code is running with regular multi-threading scenario's support, when you update the virtual dom it talks to the webview and the webview updates the UI.

There is no way they just let dotnet run inside the browser via javascript anymore, it used to be ASM.js, then webassembly was a better choice for any compiled code

[Xyncgas]

Blazor Mobile binding was an experimental project that let you write Xamarin app with blazor syntax which I love, because it's very painful for me to write Xaml app due to these products always assume there is a pattern you are following and really made it hard for me to do my own stuffs.

Blazor hybrid was the step further, since Eilon Lipton implemented mixing syntax, the scenario where you had the application mixing UI from both syntax was explored. I was very amazed by this because you can actually write web UI when you want and you can write native UI when browser lacks something you want, yet it also meant I can use multiple-threads now because the guy made it work so that there is no webassembly / javascript / server running dotnet rt.

Today's Maui.blazor is basically a re-branded name with a lot effort put into the project (before release bugs were issued and sometimes it's severe and it was resolved in preview).

Blazor Desktop was before MAUI, they made the guy's project offifical, before it was experimental. That was in .NET 6, in .NET 7 they got it a new name based on Hawaii.