Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runtime host resource types #7676

Closed
rvolosatovs opened this issue Dec 12, 2023 · 1 comment · Fixed by #7688
Closed

Runtime host resource types #7676

rvolosatovs opened this issue Dec 12, 2023 · 1 comment · Fixed by #7688

Comments

@rvolosatovs
Copy link
Member

rvolosatovs commented Dec 12, 2023

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 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:

impl DynamicResource {
    pub fn func_new<
        F: Fn(StoreContextMut<'_, T>, &[Val], &mut [Val]) -> Result<()> + Send + Sync + 'static,
    >(
        &mut self,
        name: &str, // resource method name
        func: F,
    ) -> Result<()> {
        // TODO
    }

    // And the other `LinkerInstance` counterparts
}

impl From<DynamicResource> for ResourceAny {
   // 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

@rvolosatovs
Copy link
Member Author

From discussion with @alexcrichton on Zulip in https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/Runtime.20host.20resource.20types it appears that the simplest solution here would be to:

  1. Provide means to convert Resource<T> to ResourceAny
  2. Update LinkerInstance::resource to take ResourceType as parameter

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant