-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[wasi] Add new RID for WASI #77780
Comments
Tagging subscribers to this area: @directhex Issue DetailsThe initial proposal is https://learn.microsoft.com/en-us/dotnet/core/rid-catalog
|
cc @lewing @radical @SteveSandersonMS what are the considerations for naming RID ? Also for some reason the browser wasm is not really RID. I'm confused about it, could you please help me understand ? And do the same reasons apply here too ? |
I think
We probably also want to add OperatingSystem property for WASI detection at the same time. |
In most cases we should target the WASI spec, not a particular runtime implementation. There will be a few edge cases where we want to take account of the practical realities of different runtimes rather than just the spec. For example,
In theory we shouldn't have to do anything to enable this. If a developer chooses to load their WASI-compliant module in a browser, then as long as they supply WASI-compliant import implementations, it should just work. And that does match up with what I've experienced: I've been able to run both ASP.NET Core and Blazor inside the browser after compiling them using
Ideally in the long run we'd support as much as can be supported. For features that map to specific standard runtime features, such as FS and SIMD, we'd ideally want to emit binaries that naturally work with the standard. For other features where there isn't a standard WASI API (e.g., threads today) we could choose to wait longer to see if a standard emerges, or we could choose to have an experimental-level implementation that lines up with the functionality on a particular runtime. I'd deprioritize things that aren't standardized though.
We'd want to support defining arbitrary wasm imports/exports so that people can integrate with these 3rd-party APIs. I already have half of an implementation of doing this from C# by enhancing the existing pinvoke generator :) Further out, we should look into creating a C# source generator for WIT/WITX so that any API defined as WIT/WITX can be used to generate C# bindings that builds on our support for arbitrary wasm imports/exports. What do you think? Does that all sound reasonable? |
It would be impractical to implement Such build of the runtime would have not only WASI imports, but also those dotnet specific JS interop imports.
The problem is that you need to compile for specific feature set. |
Yeah, sock_accept is the opposite direction - it's for inbound networking (TCP listeners), not for outbound networking. I wasn't suggesting anything about implementing sock_accept on top of anything else. When running in a browser there isn't any possible implementation of sock_accept, but it's not something people would expect to work.
Running in the browser is a bit of a niche so I wouldn't focus on that much. In general we should be prioritizing native interop (like mapping pinvoke to a webassembly Totally reasonable for our JS interop mechanism to work if you happen to be in a browser, but that's a small fraction of the use cases for WASI.
Absolutely. In terms of wasm features (like bulk memory etc), we would have to expose build flags to control the kind of binary output we produce. |
Oh I just realised that's a bit contradictory to our other goal of being able to standardize on this kind of build for browser-wasm too. Perhaps that's what you were referring to, in which case sorry for the confusing response! |
Yes, I'm thinking that having alternative to emscripten is good long term goal. Also I think that dotnet specific WASI/JS shim would be worth it. Regarding Regarding exposing build flags for SIMD etc. It would mean that the developer would have to have WASI-SDK installed on his machine and his CI, same way as we deploy emscripten in workload today. The other option is to have as many folders in the runtime pack as many combinations of the supported targets there are. |
Am I thinking about it right ? |
|
I think we would probably solve the different OS/runner (e.g. wasmtime) combinations with property flags than with exposing another RID. About
No |
Is there some prior attempt on this ? I don't know how that would impact behavior in runtime pack nuget. |
.net7 experimental threading support is the prior art we have
This is likely and I can imagine that we don't duplicate files that are same |
The initial proposal is
wasi-wasm
https://learn.microsoft.com/en-us/dotnet/core/rid-catalog
https://github.com/dotnet/designs/blob/main/accepted/2021/architecture-targeting.md
https://github.com/dotnet/designs/blob/main/accepted/2019/targeting-packs-and-runtime-packs.md
The text was updated successfully, but these errors were encountered: