You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given the existing component model API, the only way to invoke an exported component function for which type is not known at compile time is to use call on the instantiated function, which provides sort of "runtime reflection" for Wasm components - this works great for all functions, but the ones taking resources as parameters, as the generic call takes Val as parameter, Resource variant of which, ResourceAny, cannot be constructed at runtime by the host directly:
This type cannot be directly constructed and is only available if the guest returns it to the host (e.g. a function returning a guest-defined resource)
The proposal is to allow providing an implementation of ResourceAny by the hosts.
Benefit
This would allow for hosts to run generic Wasm components utilizing resources, for which type may not be known at compile-time by means of runtime reflection of sorts.
Implementation
I would imagine there to be a way to construct a dynamically-typed resource at runtime by utilizing functionality similar to LinkerInstance::func_new
Something like this:
implDynamicResource{pubfnfunc_new<F:Fn(StoreContextMut<'_,T>,&[Val],&mut[Val]) -> Result<()> + Send + Sync + 'static,>(&mutself,name:&str,// resource method namefunc:F,) -> Result<()>{// TODO}// And the other `LinkerInstance` counterparts}implFrom<DynamicResource>forResourceAny{// TODO}
DynamicResource most probably would have to store a reference to https://docs.rs/wit-parser/latest/wit_parser/struct.TypeDef.html or similar, uniquely identifying the resource type expected by the component, but I have not spent too much time studying this particular implementation and I am assuming resources are not duck-typed.
Alternatives
It appears that a possible alternative solution could be constructing yet another component "adapter", which would export the resource type expected, which could be instantiated and constructed by the host at runtime by instantiating the adapter component at runtime by the host. It appears that such adapter would need to be synthesized at runtime, which does not appear to be a trivial task and/or feasible in the general case
The text was updated successfully, but these errors were encountered:
Feature
Given the existing component model API, the only way to invoke an exported component function for which type is not known at compile time is to use
call
on the instantiated function, which provides sort of "runtime reflection" for Wasm components - this works great for all functions, but the ones taking resources as parameters, as the genericcall
takesVal
as parameter,Resource
variant of which,ResourceAny
, cannot be constructed at runtime by the host directly:The proposal is to allow providing an implementation of
ResourceAny
by the hosts.Benefit
This would allow for hosts to run generic Wasm components utilizing resources, for which type may not be known at compile-time by means of runtime reflection of sorts.
Implementation
I would imagine there to be a way to construct a dynamically-typed resource at runtime by utilizing functionality similar to
LinkerInstance::func_new
Something like this:
DynamicResource
most probably would have to store a reference to https://docs.rs/wit-parser/latest/wit_parser/struct.TypeDef.html or similar, uniquely identifying the resource type expected by the component, but I have not spent too much time studying this particular implementation and I am assuming resources are not duck-typed.Alternatives
It appears that a possible alternative solution could be constructing yet another component "adapter", which would export the resource type expected, which could be instantiated and constructed by the host at runtime by instantiating the adapter component at runtime by the host. It appears that such adapter would need to be synthesized at runtime, which does not appear to be a trivial task and/or feasible in the general case
The text was updated successfully, but these errors were encountered: