[WASI][draft] UnsupportedOSPlatformAttribute on the API surface

[pavelsavara]

This is adding UnsupportedOSPlatform attributes on API where WASI platform can't support the functionality.
It follows Browser OS example because

• they are both wasm targets
• they are both single-threaded by default
• they run inside sandbox which doesn't have many traditional OS APIs
• no processes, no services in WASI, no signals
• no file system notifications so far

TODO

• sockets - based on wasi-sockets in progress
• SocketsHttpHandler will be probably possible soon after. With limitations.
• net info, DNS
• System.IO.Compression.Brotli
• SSLStream vs rest of the System.Net.Security

Slowly Evolving

• Console control characters are probably possible, because wasi-cli stdio is byte-stream not character stream. But the VM would not tell us what type terminal is connected (if any).
• multi-threading seems will take at least year until it arrives. Then we will take similar approach as we have with browser. We will ship another set of ref assemblies for that build flavor.
• no crypto so far
• SmtpClient could be based on sockets, but it's low priority.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[pavelsavara]

@lewing @terrajobst does this need proper API review process ?
Or we can postpone that until the WASI target reached more maturity ?

This is quickly evolving landscape but having those attributes to give us compiler errors is useful in meantime.
So it would be good to merge something like this and evolve it incrementally.

[SingleAccretion]

Great work!

My note is that there should be an issue detailing missing WASI functionality like in your point with the terminal settings. We could (and arguably should) use it to influence future WASI APIs.

[jkotas]

multi-threading seems will take at least year until it arrives. Then we will take similar approach as we have with browser. We will ship another set of ref assemblies for that build flavor.

Shipping another set of ref assemblies is ok as a temporary solution for previews. It won't work well as a permanent solution since it is not compatible package ecosystem. The system is not setup to allow packages to ship multiple set of ref assemblies per TFM.

[pavelsavara]

multi-threading seems will take at least year until it arrives. Then we will take similar approach as we have with browser. We will ship another set of ref assemblies for that build flavor.

Shipping another set of ref assemblies is ok as a temporary solution for previews. It won't work well as a permanent solution since it is not compatible package ecosystem. The system is not setup to allow packages to ship multiple set of ref assemblies per TFM.

We already do that for browser, but we are not happy about it. What would be alternate solution ?

[jkotas]

We already do that for browser, but we are not happy about it. What would be alternate solution ?

Add a new RIDs like wasi-mt for the multi-threaded wasi variant.

Shipping second set of ref assemblies as a temporary measure makes sense only if we believe that multi-threaded wasm is going to be available everywhere relatively soon and we will be able to abandon support for single-threaded wasm.

[pavelsavara]

Add a new RIDs like wasi-mt for the multi-threaded wasi variant.

okay, thanks.

we will be able to abandon support for single-threaded wasm.

I think that improved determinism and easier ability to snapshot/hydrate memory makes single-threaded wasm long term attractive for WASI. I think that some wasm vendors don't even consider supporting MT at all.

The question remains how many server side dotnet workloads will be possible to convert to ST+async. Many existing server side codebases use blocking MT code and make network calls from synchronous methods.

We don't have to solve MT today.

[dotnet-policy-service]

Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it.