Wasmtime GitHub notifications bot (Jun 17 2022 at 15:39): Wasmtime GitHub notifications bot (Jun 17 2022 at 15:39):alexcrichton opened issue #4283:
Currently my plan for the initial implementation of the component model is to not support either importing a component from the host or exporting a component to the host. Internally a component may export and import components but this can't bubble all the way up to the host. My current plan is to write down errors for when this case arises which point to this issue.
I'm filing this to track an "official" stance in a sense where we should either commit to this implementation detail or we should figure out how to implement this. At this time avoiding importing or exporting components is a massively simplifying detail for the implementation of the component model.
If a component were to be imported it means that the component could be instantiated and then used internally, notably with fused adapters. This hinders the knowledge we have at compile-time to the point where we can't generate a fused adapter until runtime when the component is instantiated. This goes against Wasmtime's goal of being able to run code without a compiler runtime.
If a component were to be exported then a
Componentwould need to be produce-able for any internal component found. Currently we rely on this not happening and producing a fully "inlined" component representation of how to instantiate everything internal in a component. If internal components could be exported then such inlining could possibly result in $O(n^2)$ initializer instructions. This is probably easier to surmount than the previous point.
Wasmtime GitHub notifications bot (Jun 17 2022 at 15:39):alexcrichton labeled issue #4283:
Currently my plan for the initial implementation of the component model is to not support either importing a component from the host or exporting a component to the host. Internally a component may export and import components but this can't bubble all the way up to the host. My current plan is to write down errors for when this case arises which point to this issue.
I'm filing this to track an "official" stance in a sense where we should either commit to this implementation detail or we should figure out how to implement this. At this time avoiding importing or exporting components is a massively simplifying detail for the implementation of the component model.
If a component were to be imported it means that the component could be instantiated and then used internally, notably with fused adapters. This hinders the knowledge we have at compile-time to the point where we can't generate a fused adapter until runtime when the component is instantiated. This goes against Wasmtime's goal of being able to run code without a compiler runtime.
If a component were to be exported then a
Componentwould need to be produce-able for any internal component found. Currently we rely on this not happening and producing a fully "inlined" component representation of how to instantiate everything internal in a component. If internal components could be exported then such inlining could possibly result in $O(n^2)$ initializer instructions. This is probably easier to surmount than the previous point.
Last updated: Oct 23 2024 at 20:03 UTC