Stream: git-wasmtime

Topic: wasmtime / issue #7676 Runtime host resource types

Wasmtime GitHub notifications bot (Dec 12 2023 at 16:46):

rvolosatovs opened issue #7676:

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

Wasmtime GitHub notifications bot (Dec 12 2023 at 16:47):

rvolosatovs edited issue #7676:

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

Wasmtime GitHub notifications bot (Dec 12 2023 at 17:50):

rvolosatovs commented on issue #7676:

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

Wasmtime GitHub notifications bot (Jan 03 2024 at 23:46):

alexcrichton closed issue #7676:

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

Last updated: Dec 23 2024 at 13:07 UTC