Stream: wasmtime

Topic: Runtime host resource types

Roman Volosatovs (Dec 12 2023 at 16:58):

Hey everyone,

I'm currently working on invoking functionality within components, for which interface types may not be known at compile-time, meaning I can only resort to "runtime reflection" provided by wit-parser and wasmtime. I fail to see a way to call a generic function taking a (generic) resource as parameter, since ResourceAny cannot be constructed by the host at runtime https://docs.rs/wasmtime/latest/wasmtime/component/struct.ResourceAny.html

I've filed an issue https://github.com/bytecodealliance/wasmtime/issues/7676, but curious if anyone has perhaps faced the same issue already and (hopefully) found a way to solve it?

Alex Crichton (Dec 12 2023 at 17:06):

Would adding a conversion from Resource<T> to ResourceAny work for your use case? Guest resources can't be constructed by anyone but the guest, and host resources should always be modellable as Resource<T>, so I think that might cover the bases here?

Roman Volosatovs (Dec 12 2023 at 17:29):

It appears so - if it's possible to use Linker to directly provide any resource namespace:pkg/interface/x at runtime, and have a static T wrapper, which would simply represent a reference to an entry in the table, that that the dynamically-defined methods passed to Linker could use - it would work.

I'm assuming I'd just need to use func_new to define resource methods

Alex Crichton (Dec 12 2023 at 17:32):

yes I think that should all work, although I'm not sure I fully understand what you mean. I suspect that Linker is missing a method to define resources with ResourceAny, but that can be added

Alex Crichton (Dec 12 2023 at 17:33):

er, rather LinkerInstance::resource could be updated to take ResourceType instead of U

Roman Volosatovs (Dec 12 2023 at 17:35):

Yes, that's probably required - I'm not sure if resources are just duck-typed or those are concrete types and it appears it's the latter

Alex Crichton (Dec 12 2023 at 17:36):

yes resource types should always be respected and it shouldn't act like a duck-typing situation

Roman Volosatovs (Dec 12 2023 at 17:38):

Regarding the earlier question:
assume a resource type x, which contains just one method foo with no parameters and no return values.
I could use LinkerInstance::resource to assign the WIT resource type id to my Rust-land T, but how would I provide the implementation of the x.foo invoked by the component?
It appears that I'd need to define a namespace:pkg/interface/x.foo using func_new or similar, am I wrong?

Roman Volosatovs (Dec 12 2023 at 17:39):

Since x is not known at compile-time

Alex Crichton (Dec 12 2023 at 17:39):

on the same LinkerInstance that you defined the resource you'd define the method with func_new, yes, and it'd have the name [method]x.foo

Alex Crichton (Dec 12 2023 at 17:40):

this gets into how resources in WIT are translated to the component model, but you can sort of see with wasm-tools print of what the component wants

Alex Crichton (Dec 12 2023 at 17:40):

e.g. the component itself imports a function with the name [method]x.foo so it's not much more special than other functions in that regard

Roman Volosatovs (Dec 12 2023 at 17:41):

I see, that makes sense, thanks!

Roman Volosatovs (Dec 12 2023 at 17:50):

Added a comment here https://github.com/bytecodealliance/wasmtime/issues/7676#issuecomment-1852531249

I'll try to work on a PR

Alex Crichton (Dec 12 2023 at 17:57):

sounds good!

Roman Volosatovs (Dec 13 2023 at 15:13):

Looks like this should address one part of the problem https://github.com/bytecodealliance/wasmtime/pull/7680
Still not sure how to take Resource<T> into ResourceAny

Roman Volosatovs (Dec 14 2023 at 14:05):

I have a draft open at https://github.com/bytecodealliance/wasmtime/pull/7688, could you take a look to see if this aligns with what you were thinking? I'll verify if this fulfills my use case in the meantime

Roman Volosatovs (Dec 20 2023 at 13:20):

I've updated the PR, I believe it should be ready for review/merge now
I've also filed a follow-up for the reverse direction https://github.com/bytecodealliance/wasmtime/pull/7712

I know @Alex Crichton is off until next year, wondering if anyone else could take a look?

Last updated: Dec 23 2024 at 14:03 UTC