[pavelsavara]

Fixes Issue: incorrect native-library threading mode in Mono Browser MT (related to #129900).

main PR #136921

Description

Backport #136921 to release/11.0. Enable -pthread before configuring minipal and other native-library targets when Browser threading is enabled. CI produces separate ST and MT runtime packs, but previously the MT pack's minipal/System.Native objects were compiled without threading support and returned the constant native thread ID 1.

Include the native-ID test project in Browser MT smoke coverage and carry over the documentation update.

Release-specific adjustments:

• Bind the test to the existing SystemNative_GetUInt64OSThreadId entry point rather than main's newer SystemNative_GetCurrentThreadId; no production interop API changes.
• Add wasmMemory to Mono MT's INCOMING_MODULE_JS_API, preserving Emscripten 6.0.2's default entries. The release Debug runtime otherwise aborted before tests started when a worker supplied shared memory. This additional adjustment was explicitly requested while validating the backport.
• Resolve test insertion context without bringing over unrelated main-only thread-static fields.

Customer Impact

Fixes #129900

Mono Browser MT applications can receive identical native thread IDs on different threads, violating thread-identity assumptions in runtime/library synchronization code. The baseline release/11.0 native archives reproduce this directly: five concurrent threads all report 1. The related customer issue reports timer failures in multithreaded Blazor applications; that exact application failure was not reproduced here.

Without the additional incoming-API adjustment, the tested Debug MT runtime aborts at worker startup with Module.wasmMemory was supplied but wasmMemory not included in INCOMING_MODULE_JS_API.

Regression

Not established as a regression introduced in the most recent release. This is a reliability fix for the existing Mono Browser MT native-library configuration; the incorrect thread IDs were reproduced on the release/11.0 baseline.

Testing

Performed locally on release/11.0 in Debug, Mono, Browser, with threading enabled:

1. Baseline and final runtime-pack builds passed with zero warnings/errors:

   .\build.cmd -bl -os browser -subset mono.runtime+mono.wasmruntime+libs -c Debug /p:RuntimeFlavor=Mono /p:WasmEnableThreads=true /p:EnableHotReloadInRuntimeConfigDevFile=false

2. Native-relinked Thread test application in Chrome: 37 passed, 11 skipped, zero failed, including both NativeThreadIds_AreDistinctAndStable cases (one and four workers):

   .\dotnet.cmd build -bl /p:TargetOS=browser /p:TargetArchitecture=wasm /p:Configuration=Debug /p:RuntimeFlavor=Mono /p:WasmEnableThreads=true /p:EnableHotReloadInRuntimeConfigDevFile=false /p:WasmBuildNative=true /t:Test /p:Scenario=WasmTestOnChrome /p:InstallChromeForTests=false .\src\libraries\System.Threading.Thread\tests\System.Threading.Thread.Tests.csproj

3. Common tests using the prebuilt runtime pack in Chrome: 1,151 passed, zero skipped/failed:

   .\dotnet.cmd build -bl /p:TargetOS=browser /p:TargetArchitecture=wasm /p:Configuration=Debug /p:RuntimeFlavor=Mono /p:WasmEnableThreads=true /p:EnableHotReloadInRuntimeConfigDevFile=false /t:Test /p:Scenario=WasmTestOnChrome /p:InstallChromeForTests=false .\src\libraries\Common\tests\Common.Tests.csproj

   Process-local environment selected cached Chrome/ChromeDriver 151 through CHROME_PATH_FOR_TESTS and PATH. Native relinking additionally set EMSDK_PATH to the shared Emscripten 6.0.2 SDK.

4. Isolated native application linked against the actual release native archives: baseline failed with five IDs of 1; fixed archives passed with five distinct nonzero IDs stable across 1,000 reads per thread.

5. Verified all 145 generated MT native compile commands include -pthread.

The initial Debug Browser run aborted before test execution due to the missing incoming wasmMemory entry; the tests above passed after adding it. A first relink attempt needed explicit EMSDK_PATH; it was rerun successfully as described above.

Not run on this backport: ST runtime/application tests, Release configuration, full Compression suite, CoreCLR, or WASI. This does not claim that the original .NET 10 timer reproduction was executed.

Risk

Scoped to Browser MT builds. Native compiler/linker flags now match the requested threading configuration; ST and non-Browser flag conditions are unchanged. This affects multiple native libraries, so risk is not zero, but the release runtime pack builds and both prebuilt and native-relinked Browser test paths pass.

The additional wasmMemory allowlist change is MT-only and retains the pinned Emscripten version's default incoming API entries. No public managed API or minipal implementation changes.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

Note

This pull request was generated with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 4 pipeline(s).
11 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @VSadov
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

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

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[pavelsavara]

After doing more testing I was not able to establish that this fix is necessary on Net11 and below.
It is the correct thing to do, but I was not able to prove this meets the servicing bar. Especially because MT is not supported configuration.

[Frulfump]

Should this be moved out of the milestone and have Servicing-approved removed so it doesn't show up when looking at https://github.com/dotnet/runtime/issues?q=milestone%3A11.0.0%20is%3Aclosed%20label%3Aservicing-approved ?