wasmtime / PR #7688 feat: allow construction of guest-def... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #7688 feat: allow construction of guest-def...

Wasmtime GitHub notifications bot (Dec 14 2023 at 13:59):

rvolosatovs opened PR #7688 from rvolosatovs:feat/dynamic-resources to bytecodealliance:main:

Closes https://github.com/bytecodealliance/wasmtime/issues/7676
Follow-up on #7680

This feature requires changes in the resource table to allow specifying the ResourceType associated with the resource stored (since assumption that it's always equal to ResourceType::host::<T>() is no longer valid

Wasmtime GitHub notifications bot (Dec 14 2023 at 14:01):

rvolosatovs updated PR #7688.

Wasmtime GitHub notifications bot (Dec 14 2023 at 14:03):

rvolosatovs edited PR #7688:

Closes https://github.com/bytecodealliance/wasmtime/issues/7676
Follow-up on #7680

This feature requires changes in the resource table to allow specifying the ResourceType associated with the resource stored (since assumption that it's always equal to ResourceType::host::<T>() is no longer valid)

Wasmtime GitHub notifications bot (Dec 14 2023 at 16:06):

alexcrichton commented on PR #7688:

I think I might have missed something in this by accident perhaps. I don't think that this is the direction things should go in, for example Resource<T> is designed to have a statically known type as ResourceType::host::<T>() as opposed to a runtime-defined type. Having a runtime-defined type sort of defeats the purpose of the type parameter which at that point require a redesign of the resource-related APIs.

The title of this PR though, allowing host creation of guest resources, is not something Wasmtime can enable. Just as guests can't create host-defined resources without asking the host to do so the other way around is the same. The host can't conjure a guest resource out of thin air, it must originate in the guest.

Given that I fear I might have missed some motivation/use case when talking about this, could you perhaps clarify?

Wasmtime GitHub notifications bot (Dec 14 2023 at 16:16):

rvolosatovs commented on PR #7688:

Given that I fear I might have missed some motivation/use case when talking about this, could you perhaps clarify?

Here's a more concrete example of the use case:

Assume the following WIT:
interface types {
    use wasi:io/poll@0.2.0-rc-2023-11-10.{pollable};

    resource future-string {
        subscribe: func() -> pollable;
        get: func() -> option<string>;
    }
}

interface example {
    use types.{future-string};

    foo: func(future-string);
}

world opaque-world {
    export example
}
And a component exporting the example interface.

The intention is to call example.foo on the component without having the WIT at compilation time, i.e. parsing the WIT from the Wasm itself at runtime (which works already) and then invoking example.foo within the component.
The only blocker for this now is the fact that the host cannot construct future-string at runtime if it does not have the future-string WIT definition available at compilation time (and associated bindings)

The host, however, can already push a Resource to the table and link the associated methods on the linker, the only bit left is being able to turn the Resource constructed at runtime into a ResourceAny to be able to invoke the function via call or call_async

Wasmtime GitHub notifications bot (Dec 14 2023 at 16:20):

rvolosatovs edited a comment on PR #7688:

Given that I fear I might have missed some motivation/use case when talking about this, could you perhaps clarify?

Here's a more concrete example of the use case:

Assume the following WIT:
interface types {
    use wasi:io/poll@0.2.0-rc-2023-11-10.{pollable};

    resource future-string {
        subscribe: func() -> pollable;
        get: func() -> option<string>;
    }
}

interface example {
    use types.{future-string};

    foo: func(opaque: future-string);
}

world opaque-world {
    export example;
}
And a component exporting the example interface.

The intention is to call example.foo on the component without having the WIT at compilation time, i.e. parsing the WIT from the Wasm itself at runtime (which works already) and then invoking example.foo within the component.
The only blocker for this now is the fact that the host cannot construct future-string at runtime if it does not have the future-string WIT definition available at compilation time (and associated bindings)

The host, however, can already push a Resource to the table and link the associated methods on the linker, the only bit left is being able to turn the Resource constructed at runtime into a ResourceAny to be able to invoke the function via call or call_async

Wasmtime GitHub notifications bot (Dec 14 2023 at 16:33):

rvolosatovs commented on PR #7688:

Another way to look at this would be the following:

If one could pass a wasmtime::component::Val::U32, which stores the Resource::rep value as a function parameter directly where a resource is expected, that would cover the use case.

Perhaps a an even more generic view on this could be allowing arbitrary impl Lower values to be passed as arguments to call/call_async (or yet another alternative)

This all really boils down to being able to pass the resource index to a component in cases where the resource type is not known at compilation time

Wasmtime GitHub notifications bot (Dec 14 2023 at 17:02):

rvolosatovs edited a comment on PR #7688:

Another way to look at this would be the following:

If one could pass a wasmtime::component::Val::U32, which stores the Resource::rep value as a function parameter directly where a resource is expected, that would cover the use case.

Perhaps an even more generic view on this could be allowing arbitrary impl Lower values to be passed as arguments to call/call_async (or yet another alternative)

This all really boils down to being able to pass the resource index to a component in cases where the resource type is not known at compilation time

Wasmtime GitHub notifications bot (Dec 14 2023 at 18:44):

github-actions[bot] commented on PR #7688:

Subscribe to Label Action

cc @peterhuene

<details>
This issue or pull request has been labeled: "wasi", "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Dec 15 2023 at 15:02):

rvolosatovs updated PR #7688.

Last updated: Dec 13 2025 at 19:03 UTC