WASI support tracking #65895
Comments
|
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsDescriptionThis issue is to track known issues in the early WASI-enabled runtime builds. These need to be resolved in order to have a proper supportable WASI-ready release.
Reproduction StepsExpected behaviorActual behaviorRegression?No response Known WorkaroundsNo response ConfigurationNo response Other informationNo response
|
dotnet-issue-labeler
bot
added
the
untriaged
lambdageek
removed
the
untriaged
lambdageek
added
the
tracking
|
Is exporting functions to wasi tracked here too? |
Added |
|
@pavelsavara Thanks! We also need the opposite: Exporting functions so that you can create a .NET library and compile it to wasm and consume it from the other languages. It's already possible from Go, C, C++, and Rust. See this sample: https://github.com/extism/csharp-pdk/blob/master/samples/SamplePlugin/Functions.cs#L9 Currently you have to write the C glue code manually: https://github.com/extism/csharp-pdk/blob/master/samples/SamplePlugin/native.c#L11 |
That would be Also there trouble is sharing memory between caller and called code. We will implement this assuming shared memory (with the host engine) and passing pointers. And the "WASI component model" with isolated memory, lowering/lifting etc will need different attributes in the future future. |
Sorry for the delay, personal stuff came up and haven't completely caught up with the backlog. |
|
I think it would be cool to have the ability to completely disable Exception-Handling and the GC or other parts of the framework that blow up wasm-size and slow down startup-time. Chrome for example now has WasmGC and other hosts will likely have their own GC-implementations, too. For fire-and-forget-style exectutions where a really small wasm with fast startup-time is needed like cloudflare workers or (I personally think this case is much more important) smart contracts, this could be a great advantage and further diversify the use of C#/.NET. |
|
Is it possible to define import memory with wasi-wasm (with C glue code or otherwise)? And if so, are there any examples on how to access imported memory? I've used attribute((import_module("..."), import_name("..."))) and attribute((export_name("..."))) for importing/exporting functions, but haven't seen any documentation or examples on importing and exporting wasm Memories/Tables/Globals. Similarly, is it possible to adjust the size of the exported memory? By default it appears to export 800 pages, but is there a setting to customize this? |
|
Couldn't find a good place to ask this and not sure if it's worth raising an issue, so for now I'll just ask here: why does Android, iOS, tvOS etc have no relation to WASI or Wasm, so... are they pulled because they're implicit dependencies of Mono itself? Or some other reason? |
|
|
Here are the scenarios how we would like to use Wasi:
Edge/Customers with self hosted environmenments where kubernetes is problematic: We primarily have cloud offerings, but some customers cannot have their data in the cloud and have their own self hosted environments: That would be for example Hospitals in some countries which do not want their patient data in the cloud, or for example Patent lawyers, who have unreleased Patents which could be of Interest to Microsoft/Amazon/Google and customers of these Patent lawers require in contracts that unreleased Patents not to be uploaded in any Cloud Service. Some of these Customers do just have 2-3 IT Personell and don't want to service their own kubernetes cluster, here a service mesh based on wasi/Wasmtime would be very interesting. Even for us automating the setup of a self hosted kuberentes cluster is not easy even with modern Kubernetes Solutions Also is it not always possible to have Linux VMs with a Kuberentes in an Windows Only Environment. Be it for compatibility with customer required mandatory virus scanners, lack of knowlege of Linux Administration, or Licencing Situations which only allow Windows VMs and not Linux VMs (Windows Server, VMWare).
|
@MichaelPeter Can you help me understand how WASI helps in the 1st case over just running dotnet on the hardware today? I see the benefit for platform owners that want to run anything, but I'm having a hard time understanding how it helps developers? What does it mean to build and deploy a WASI service in this situation? Where are you deploying? What orchestrates your services? Without k8s what does networking?
Are we talking about some new device that has a native WASM runtime? What is this exactly?
Lots of ideas here but WASI doesn't solve this. There are many other architectural problems to tackle with Azure functions so that this benefit can be observed. |
These are very good questions and I see too: what benefit has WASI that I can not already do with Native Applications? I see Wasmtime or different Wasm runners here as Platform that provides Networking, at least for now on a single maschine for Platform Owners. But here the WASI Commuity Group is not yet far enough with Networking and many other things... Alternativly frameworks like Aspire could abstract away the underlying Networking for WASI Runner-Platform and/or Kubernetes Platform. Where do I deploy? Everywhere, where I can start a Wasi Runner (Windows Server, Developer/Sales Laptop, What are the Advantages for the Developer: For Testing he doesn't need a whole Kubernetes Cluster on his Developer PC, only a WASI runner. But then still Who does Updating? there are WASI/WASM Container registries, but no Gitops Platforms yet like ArgoCD/Flux to automatically update... But as you said these are just Ideas and no concrete use cases |
I meant for distributed systems, not networking APIs that WASI may describe.
Sure but that has yet to manifest. I'm also not convinced it will be that different to Kubernetes at the core.
You can run your apps today locally on your PC without Kubernetes. This isn't a feature unique to WASI. I'm very supportive of the work to make .NET work with WASM on the server side, but the ecosystem barely exists so the benefits called out are hypothetical and in the early idea stage. There are a few platforms and tools that can run WASM binaries but from a .NET developer point of view, it seems like an implementation detail. |
|
This is a great conversation and helps to flush out a lot of the ambiguity that surrounds WASI today. It's important to know that WASI (i.e., a combination of API interface definitions for things like HTTP requests, plus tooling like Long term it's completely possible that K8s devs will commonly run WASI components in preference over traditional containers within their Kubernetes clusters. Or maybe that some WASI-first K8s alternative will emerge, though as @davidfowl says it would probably look the same as Kubernetes from the point of view of the person deploying and maintaining the cluster itself. However, neither of these things are definite, and the WASI ecosystem remains at an early stage. |
|
Having possibility to run ASP.NET WebApi project on system that don't have .net supported (ex. *BSD and/or exotic arch) would be +1 for me. It was possible using https://github.com/SteveSandersonMS/dotnet-wasi-sdk and implementing http host under wasmrunner to interop with .net or using the one with WASI tcp-level where available - is/will that be planned/supported in future? |
Right! I was hoping somebody would have a scenario around that.
Are you expecting a very small binary with a tiny performance hit? WASI is experimental and we don't be shipping anything non-experimental on top of it until it goes stable. Our path for WASM on the server should be based on the work we've been doing to make ASP.NET Core NativeAOT compatible (and this is a long journey 😄). |
FWIW we're currently experimenting with Wasm support via NativeAOT-LLVM experiment (https://github.com/dotnet/runtimelab/tree/feature/NativeAOT-LLVM) and had a very good experience performance-wise. The only blockers are that it's experimental and that it currently builds only on Windows. Other than that, it's pretty competitive with Wasm compiled from Rust (except for binary size, but that's not very important to us anyway), especially compared to the Mono interpreted version. Hoping that the cross-platform variant of NativeAOT will get to similar level feature- and performance-wise someday, or that NativeAOT-LLVM experiment will make it into mainstream. That said, in our project we're not interested in WASI but in pure Wasm as we provide custom host functions. WASI target is just means to an end because in .NET there is currently no option for |
|
Right, I was just hoping to use @davidfowl As for performance and binary size - that's something I wouldn't care for at the start, as having possibility to run .net code on new platform/os without "native" runtime would be more important IMO (sure NativeAOT would be way better, but as you said, it's a journey :) |
|
@sec Then the current support is likely fine for you without native aot 😄 |
|
Another usage scenario are server side plugins, @SteveSandersonMS showed it already in his demos, but wanted to mention it again. On self hosted environments by customers, computation is not that expensive and our server side applications can load Plugin DLLs (from us or third party) and run them into the server process. There is always the risk of memory leaks, infite loops and reduced performance but it can be tolerated. On Cloud environments this is not tolerable anymore, since one plugin DLL could bring down all customers, also there is the risk of data of other customers can be accessed. So third party Plugin Developers need to host REST/GRPC Services for their plugins which then need to be integrated. This is much more complex and much slower than a DLL. Or there need to be a whole infrastructure for hosting third party docker containers. With WASI, we could still load the WASI-File-Plugins in Our Application, data of other customers could not be accessed (or at least an acceptable risk if no error on our side), we could limit the amount of CPU resources to disable slow plugins It also would be importaint that it can be configured that only certain Rest/Socket resources can be accessed, or for example only external and no Lan-Endpoints. (be it by IP-Ranges or other means) |
AFAIK WASM runtimes (the ones I've seen) don't let you limit CPU usage of running code (you can limit the memory) .NET process host -> Some WASM runtimes-> .NET code compiled to WASM running inside of those runtimes. Of course, these systems are not "just secure" as you need to audit the host code and WASM runtime code to make sure bugs don't lead to leaking customer data across... I think we will see plugins using WASM more and more so that's a reasonable scenario. |
Wasmtime has the concept of "fuel": https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.consume_fuel But, it's different from docker's cpu limits, it's more about preventing infinite loops |
|
Another point - is debuggability of production environments vs. chiseled-docker In one project we switched to chinseled dotnet containers a few days ago and now we have the problem that debugging is much more limited of production environments since there is no shell. Now one could argue well then keep the shell installed for production, well then the container is bigger and its a potential security risk. Wasi would allow a "sidecar"-wasi written for example in rust for .NET, which could be included in the "wasi-container" But yes, most of this tooling doesn't exist yet. |
|
Is there any way to produce raw Wasm MVP files from .NET 9 after #104683 has landed? We've been "piggy-backing" on .NET's Wasi target to produce Wasm files targeted for custom hosts, as, unlike C/C++/Rust/etc .NET doesn't have support for raw ("hostless") Wasm output and WASI is the closest target where we could simply stub out all the imports during compilation and rely on This has been possible starting from the original @SteveSandersonMS' Wasi.Sdk and up until and including .NET 8. I now wanted to try and test how hard it would be to migrate to .NET 9 preview as it has some exciting Wasm features - in particular, AOT and Which brings me to the crux of my question - is there any way path to opt-out from Wasm component output or, even better, an official example that shows how to produce a raw "hostless" Wasm in plain old MVP format, going to be provided in .NET 9 or does this mean we're stuck with .NET 8 with its slow interpreter mode for IL bytecode for the foreseeable future? UPD: I should probably add that, by decomposing components into individual Wasm files using |
|
We switched to WASI preview 2 and component model in Net9 Preview 7. We now depend on wasi:http component import directly. We don't have dev bandwidth to support multiple build configurations, I'm sorry. |
|
I imagine that's going to break quite a few users in similar positions to us. Out of curiosity, what was the driver behind that decision? Wasm components are still in rather raw stages, and the engine support is pretty poor compared to regular Wasm. While it's interesting to watch its development, it seems rather too early to switch to it as the primary output format for stable .NET version, cutting off majority of engines other than I guess Wasmtime. Perhaps there is some So, while I totally understand lack of bandwidth for actual development & support, perhaps there is a way to just provide a different link-stage flag so that .NET would produce just this one single file, which already has the required shape? We can do the rest of the stubbing ourselves. |
|
You could try disable We are also passing Here is WASM & WASI ABI, I'm not sure which of them would apply.
"Skate to where the puck is going, not where it has been." |
Thanks, this is helpful, going to take a look.
Yeah I suspect this is going to be a problem, too. I looked at it briefly before, and I think I could hack around it with MSBuild's
That is fine, since we are going to stub them out anyway, it doesn't matter which version is used. On the C ABI side it still behaves like a regular C import, after all, so declaring stubs isn't very different from the original preview. It's really just the components + WIT that cause issues, which is why I'm hopeful that what we want is achievable with purely a link-time change.
Heh, I agree with the sentiment, just saying it feels... risky / early for a switch, given the very limited native engine support. I liked WASI p1 for its simplicity and compatibility with any regular Wasm, and was one of probably dozens of people who made their own in-browser implementations at the time because it was just a matter of loading same Wasm file but with custom imports. Oh well, either way that's beside the point for this particular usecase. |
For Net10 possibly yes. But I'm afraid we will break it again ... let's give it a try. |
Description
This issue is to track known issues in the early WASI-enabled runtime builds. These need to be resolved in order to have a proper supportable WASI-ready release.
wasi-wasmRIDOperatingSystem.IsWasi()#78389 API changeSystem.Nativeusing WASI SDK instead of using the Emscripten-built binary.wasm_m2n_invoke.g.hSystem.Native. Currently there's a small hardcoded list.dotnet/wasi-sdk)dotnet/wasi-sdkpackages #95086mono_gc_finalize_notifyingc.c).synthetic-pthread.ccode to support having separate pthread keys for each thread instead of a single global list.ves_icall_System_Reflection_Assembly_InternalLoad. #95137[DLLImport]which doesn't match known static native symbols #86984[UnmanagedCallersOnly]#86985Build
and a public distribution mechanism.wasi-experimentalworkload,wasiconsoletemplate, andWasi.Build.Tests#81849)wasi-experimentalworkload,wasiconsoletemplate, andWasi.Build.Tests#81849)wasi-experimentalworkload,wasiconsoletemplate, andWasi.Build.Tests#81849)wasi-experimentalworkload,wasiconsoletemplate, andWasi.Build.Tests#81849)wasi-experimentalworkload,wasiconsoletemplate, andWasi.Build.Tests#81849)The text was updated successfully, but these errors were encountered: