Troy Edwards (Sep 17 2024 at 14:08): Troy Edwards (Sep 17 2024 at 14:08):I see that with WAC you can compose two WASM components together into a single binary. But what if for example, I'm creating a sandboxed scripting engine for game where user-created scripts? In this case, I don't necessarily want the user to have the main game binary or more importantly, have to pack it into their binary and include the entire game when it's executed at runtime where the main game WASM should already be there and it should be interacting with the memory space of the main game module, and perhaps don't even have access to system calls / io?
I see that you can define imports for wasm components using Wasmtime in Rust (https://docs.wasmtime.dev/api/wasmtime/component/bindgen_examples/index.html), but that seems to require manually defining import bindings and calling the other module, essentially having to link it myself manually through bindings in code. Is there some way to link at runtime with Wasmtime? How do I automatically link the two and allow it to say, access resources and records from the other WASM module at runtime?
Alex Crichton (Sep 17 2024 at 15:02):It's perhaps worth noting that wasm components represent a sealed boudary between each other. A component can't tamper with the memory space of any other component, so if two components are composed together with wac then the two components can't tamper with each other as they're constrained by the component model APIs they're using to communicate with each other. In that sense you wouldn't have to worry about a user script interfering with another component.
When working with imports/components at runtime you don't have prior static information about you'll want to use the "untyped" APIs. This will involve some reflection on the component at hande and using APIs such as Linker::func_new and Func::call
Pavel Šavara (Sep 18 2024 at 06:40):I wonder if WASI is capable to support true plugin-at-runtime. That is I want to allow each user to choose different set of plugins at runtime, download them from OCI at runtime and instantiate them. Multiple instances, which implement the same WASI interface. All of that as guest component, not by wrapping (wasmtime) host.
So I guess we need
1) host API which would do the instantiation
2) some way how to dispatch otherwise "static" method call to different component instance. Maybe some component virtualization.
Ralph (Sep 18 2024 at 08:29):I believe that comes with preview 3, but I defer to those who have actual knowledge instead of pretend knowledge.
Joel Dice (Sep 18 2024 at 13:30):AFAIK, there are no concrete plans to support runtime code loading in an official way (neither in preview 3 nor beyond), although you can always do it in a custom host embedding. For example, https://github.com/rylev/wepl demonstrates loading a component dynamically and invoking its exports.
IFcoltransG (Sep 18 2024 at 20:56):Ralph might be thinking of Luke Wagner's suggestion in the WASI/database pooling thread of looking at runtime module instantiation between Preview 3 and the first WASI release candidate. I imagine loading new code at runtime would have extra challenges on top of that.
Joel Dice (Sep 18 2024 at 21:09):Yeah, the "runtime instantiation" feature Luke was talking about would only allow instantiating statically-known components AFAIK. It wouldn't necessarily allow a guest to e.g. download a component on the fly and instantiate it.
Colin Marc (Sep 18 2024 at 21:16):Joel Dice said:
Yeah, the "runtime instantiation" feature Luke was talking about would only allow instantiating statically-known components AFAIK. It wouldn't necessarily allow a guest to e.g. download a component on the fly and instantiate it.
I think you might be in the wrong thread :)
Notification Bot (Sep 18 2024 at 21:20):2 messages were moved here from #general > recvmmsg / sendmmsg by Joel Dice.
Last updated: Dec 23 2024 at 12:05 UTC