Wasmtime GitHub notifications bot (Nov 06 2023 at 10:16): Wasmtime GitHub notifications bot (Nov 06 2023 at 10:16):jeffparsons opened issue #7485:
Originally discussed on Zulip here: https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/Sharing.20generated.20code.20between.20same.20interface.20import.2Fexport
It would sometimes be convenient to share the generated types between imports and exports of an interface, e.g. if one component calls the host though a given interface and then the host forwards the call to some other component in an entirely separate instance using the same interface.
This is currently not possible, and so conversion between the structurally-identical but separate types must be done manually. If there is a good reason why the imported and exported WIT types should be generated as separate Rust types, perhaps conversions between them should be generated for when you know that's what you want to do?
Wasmtime GitHub notifications bot (Nov 09 2023 at 02:28):jeffparsons edited issue #7485:
Originally discussed on Zulip here: https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/Sharing.20generated.20code.20between.20same.20interface.20import.2Fexport
It would sometimes be convenient to share the generated types between imports and exports of an interface, e.g. if one component calls the host though a given interface and then the host forwards the call to some other component in an entirely separate instance using the same interface.
This is currently not possible, and so conversion between the structurally-identical but separate types must be done manually. If there is a good reason why the imported and exported WIT types should be generated as separate Rust types, perhaps conversions between them should be generated for when you know that's what you want to do?
EDIT: Another use case this would help is extending generated types with extra behavior and sharing that through a crate.
Wasmtime GitHub notifications bot (Nov 09 2023 at 18:38):alexcrichton commented on issue #7485:
I think one way to possibly solve this would be to create some sort of has for a type which models the structure and then deduplicate based on this hash. That would chiefly have to incorporate differences in resources and additionally details like borrowing specific to Rust. Afterwards deduplication based on that shouldn't be too too hard.
Wasmtime GitHub notifications bot (Nov 11 2023 at 02:32):jeffparsons commented on issue #7485:
Small tangent: it sounds like this could also be used for the dynamic representations to avoid the need for deep equivalence tests on each call. Does that sound right?
Wasmtime GitHub notifications bot (Nov 13 2023 at 16:42):alexcrichton commented on issue #7485:
Sorry I'm not sure what you mean, can you clarify?
Wasmtime GitHub notifications bot (Dec 24 2023 at 02:39):jeffparsons commented on issue #7485:
Ah, sorry, I forgot about this.
There's a decent chance I've misunderstood something, but my current understanding is that when you call a component function from a host dynamically (i.e. using
wasmtime::component::Func), it first performs a deep structural type-check.If all types that are capable of structural equivalence had a content hash associated with them, could that be used in an additional fast path in
checkto save from doing the deep structural check with every call? Maybe this is only relevant when taking values from one store and passing them to a different store (otherwise it looks like there is an existing fast path??) but that is a use case that is important to me.All that said, I'm not actually champing at the bit for higher performance or anything; I'm currently only tinkering on hobby stuff, and only mentioned this at all because I'd been looking at the relevant code recently and wondered if it would be low-hanging fruit in a future world where component types already had a convenient hash hanging around.
Last updated: Oct 23 2024 at 20:03 UTC