Repository navigation
Provide interface to spawn a new wasm component #763
Description
I know this involves a lot of design work and problems to tackle. Yet, in the long run I think the need for spawning wasm components will arise. In my naive view the interface would expect the binary component code and allow for composition to, e.g., pass stdin stream data and read stdout stream data from the currently running component. Since this consumes new host memory, the spawning is allowed to fail due to runtime memory limits.
One could emulate this behavior by running a wasm interpreter (since bytecode generation would not help) but it bloats the overall binary size and the speed of the spawned component would be slow. Also, I think that this would be the last piece in a real "wasm OS" where the part that compositions components does not need to be native code and thus any wasm runtime can run it. Think about a simple wasm shell - one can do this in native code or JS for the browser but not in wasm as of now.
Activity
lukewagner commentedon Sep 27, 2023
I think you're right that we need a way to spawn a new component at runtime; there are plenty of great use cases for that (some already documented in the Component Model's UseCases.md here. When you dig into how efficient linkage and lifetime management (of these component instances) should work, I think the right place to add this functionality is in the Component Model directly, as a runtime-callable variant of the existing
instantiateexpression, returning an owned handle to the new instance. (Early in the process of proposing the Component Model, I had this slide showing the spectrum of options and their implications, and "runtimeinstantiate" corresponds to the second-to-leftmost column.) Unfortunately, I think this might take a bit more time (I think it's the next big feature to add after native async support, although perhaps some of the work is parallelizable with async).justinfagnani commentedon Feb 20, 2026
I'm trying to build a WASI component orchestrator that itself runs in WASM, and could really use an interface like this. Right now I have to provide imports in JS that wrap WebAssembly.instantiate() or build a wrapper runtime over something like wasmtime that can supply a custom WIT interface that allows it.