[browser] Enable threads in Wasm SDK

[maraf]

• Allows threads for blazor
• Publish dotnet.worker.js when threads are enabled
• Append fingerprint for dotnet.worker.js
• Support for dotnet run requires [blazor] Set Cross-Origin-Policy headers for multi-threaded runtime aspnetcore#47855

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

null

Author:	maraf
Assignees:	maraf
Labels:	arch-wasm, area-Build-mono
Milestone:	8.0.0

[lambdageek]

How do I try this out?

[maraf]

The same story as for webcil. Until SDK PR lands and makes through installer, you need a lot of manual patching. I can show you tomorrow if you want.

[lewing]

wait for dotnet/sdk#31912 to have an installer build then you can use wbt on this pr

[maraf]

wait for dotnet/sdk#31912 to have an installer build then you can use wbt on this pr

That one is not enough. This is needed dotnet/sdk#31519

[lewing]

dotnet/installer#16197

[lambdageek]

I tried this one the same way as #84977 (comment) but I don't see dotnet.worker.js in wwwroot/_framework if I do dotnet run.

With dotnet publish it's there

[lambdageek]

Getting some blazor errors about blazor-internal not being loaded yet.

Seems like some of the blazor async code is running on worker threads instead of the main thread. no that's not it. the message is from the main thread.

azor.webassembly.js:1 Error: Assert failed: ES6 module blazor-internal was not imported yet, please call JSHost.ImportAsync() first.
Lt @ blazor.webassembly.js:1
worker.onmessage @ dotnet.8.0.0-dev.pry02bjaoa.js:11

This seems to happen pretty much as soon as I click around between pages when using the threaded runtime. threads don't actually need to be used. I think it's maybe something from the NavMenu, probably this one:

https://github.com/dotnet/aspnetcore/blob/d07f377b6c4c72f44a0eb2810c8abf1ae3fabd40/src/Components/WebAssembly/WebAssembly/src/Services/InternalJSImportMethods.cs#L77

blazor-internal is supposed to be set up with setModuleImports

https://github.com/dotnet/aspnetcore/blob/d07f377b6c4c72f44a0eb2810c8abf1ae3fabd40/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts#L337

So it seems like maybe setModuleImports isn't working right on the main thread with the threaded runtime for some reason.

Ah interesting. if I set a breakpoint just before we do that "ES6 module ${js_module_name} was not imported yet, please call JSHost.ImportAsync() first." error, I see that I'm actually in a worker thread (!!)

So somewhere the blazor code ends up running some async code on a new thread after all. and then setModuleImports hasn't happened on the worker, so the module isn't loaded there.

I think it might be

https://github.com/dotnet/aspnetcore/blob/d07f377b6c4c72f44a0eb2810c8abf1ae3fabd40/src/JSInterop/Microsoft.JSInterop/src/Infrastructure/DotNetDispatcher.cs#L118

I'm not sure that task.ContinueWith(..., TaskScheduler.Current) would respect the synchronization context - I think it always queues up a work item for the threadpool.

[lambdageek]

Also the blazor weather forecast page from the default template breaks because http fetching has a ConfigureAwait(false) somewhere. @pavelsavara, I think we need to fix that HTTP client thing that you found

   Unhandled exception rendering component: The JavaScript object can be used only on the thread where it was created.
System.InvalidOperationException: The JavaScript object can be used only on the thread where it was created.
   at System.Runtime.InteropServices.JavaScript.JSObject.AssertThreadAffinity(Object )
   at System.Net.Http.BrowserHttpInterop.AbortResponse(JSObject )
   at System.Net.Http.WasmFetchResponse.Dispose()
   at System.Net.Http.BrowserHttpContent.Dispose(Boolean )
   at System.Net.Http.HttpContent.Dispose()
   at System.Net.Http.HttpResponseMessage.Dispose(Boolean )
   at System.Net.Http.HttpResponseMessage.Dispose()
   at System.Net.Http.Json.HttpClientJsonExtensions.<<FromJsonAsyncCore>g__Core|4_0>d`2[[bl1.Pages.FetchData.WeatherForecast[], bl1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null],[System.Text.Json.JsonSerializerOptions, System.Text.Json, Version=8.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51]].MoveNext()
   at bl1.Pages.FetchData.OnInitializedAsync()

[pavelsavara]

Also the blazor weather forecast page from the default template breaks because http fetching has a ConfigureAwait(false) somewhere. @pavelsavara, I think we need to fix that HTTP client thing that you found

Here is the draft, but I need to try on top of your branch. #85244

I wonder if also user code would have to contain ConfigureAwait(true) on all lines with await keyword. If so, that means massive inconvenience even for our HTTP unit test suite

Edit: ConfigureAwait(true) is default behaviour

[lambdageek]

@maraf Any reason this is still draft? I think this PR is working, even if the libraries and blazor need a bit of work.

[lambdageek]

Fingerprinting stuff is working. I see fetches for dotnet.worker.8.0.0-dev.p6hue5g3ye.js and the webworkers are starting properly.

[maraf]

Failures are unrelated