[browser][MT] public API of threading, like new Thread vs PNSE

[pavelsavara]

We have [UnsupportedOSPlatform("browser")] on many multi-threading APIs.
We also have

• System.Threading.Thread.WebAssembly.Threading\ref
• System.Threading.ThreadPool.WebAssembly.Threading\ref
• System.Diagnostics.Tracing.WebAssembly.PerfTracing\ref
  which is overlaying that for Browser runtime pack.
  That confuses Roslyn analyzers.

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

Issue Details

---

We have [UnsupportedOSPlatform("browser")] on many multi-threading APIs.
We also have

• System.Threading.Thread.WebAssembly.Threading\ref
• System.Threading.ThreadPool.WebAssembly.Threading\ref
• System.Diagnostics.Tracing.WebAssembly.PerfTracing\ref
  which is overlaying that for Browser runtime pack.
  That confuses Roslyn analyzers.

Author:	pavelsavara
Assignees:	pavelsavara, lambdageek
Labels:	arch-wasm, area-System.Threading
Milestone:	8.0.0

[lambdageek]

This used to work: if you added project references to the threaded ref assemblies, they would be picked up in preference to the single-threaded ones. But there's maybe now some issue with the browser TFM? /cc @lewing

[lambdageek]

I guess an alternative is to always allow calls like Thread.Start at compile-time and only throw PNSE at runtime. But that sucks for the majority of WASM projects since they won't be using threading

[lambdageek]

It would be great if the platform compat analyzer also could support some attribute that used feature flags as guards. something like [SupportedOSPlatform("browser", FeatureFlag="System.Thread.IsThreadStartSupported")]. And then we could set the feature flag based on project settings.

That would also let us do things like build certain projects with SIMD or WASM-EH disabled and hide the corresponding intrinsics APIs. Or maybe make some APIs unavailable on ios unless the interpreter is enabled, etc