Stream: git-wasmtime

Topic: wasmtime / issue #7646 `bindgen!` support for linking com...

view this post on Zulip Wasmtime GitHub notifications bot (Dec 06 2023 at 10:44):

rylev opened issue #7646:

Feature

Add support through the bindgen! macro for adding a component instance to the linker as the backing implementation for a import.

Currently bindgen! gives support through add_to_linker for specifying an implementation for an import that dispatches to a type that conforms to a trait which matches the import's signature. This feature would add an additional function add_component_to_linker which would do the same but instead of dispatching to a trait function implemented on a type, it would instead dispatch to a component instance.

Benefit

This has all the benefits associated with WebAssembly itself. Import implementations can be sandboxed so that even untrusted code can be run as an import implementation. This provides an easy way for users of wasmtime to implement "plugin" systems for their import implementations.

Implementation

Most likely the bindgen! macro would gain the ability to generate a function add_component_to_linker function on world structs much like the current add_to_linker function.

This function would have the following signature:

/// Add component as a backing implementation to `linker`
///
/// The component will run against `store` and can have its own imports satisfied by `other_linker`
fn add_component_to_linker<T, U>(
        linker: &mut Linker<T>,
        other_linker: &Linker<U>,
        other_store: Store<U>,
        other_component: &Component,
) -> anyhow::Result<()>;

This signature would allow user's complete control over the linked other_component including the ability to turn on wasi support or even implement imports for that component.

The implementation would instantiate component against other_linker and other_store which would be wrapped in a Mutex and moved inside the wrapped import of linker's root instance. When linker's wrapped import function gets called, the mutex will be locked and the other_component instance will be called with the exact same arguments coming from the outer component.

Alternatives

The signature for add_component_to_linker is a bit awkward (especially due to taking a second linker). This is to maximize the user's ability to control the other_component instance. We could simplify the signature at the expense of this user control.

It's also possible for users to implement this without the help of wasmtime or the bindgen! macro; it's just fairly finicky code. While it would certainly be helpful for wasmtime to provide this functionality, it does not unlock new use cases that weren't possible before. Therefore, an alternative would be to just not do this.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 06 2023 at 13:41):

rylev edited issue #7646:

Feature

Add support through the bindgen! macro for adding a component instance to the linker as the backing implementation for a import.

Currently bindgen! gives support through add_to_linker for specifying an implementation for an import that dispatches to a type that conforms to a trait which matches the import's signature. This feature would add an additional function add_component_to_linker which would do the same but instead of dispatching to a trait function implemented on a type, it would instead dispatch to a component instance.

Benefit

This has all the benefits associated with WebAssembly itself. Import implementations can be sandboxed so that even untrusted code can be run as an import implementation. This provides an easy way for users of wasmtime to implement "plugin" systems for their import implementations.

Implementation

Most likely the bindgen! macro would gain the ability to generate a function add_component_to_linker function on world structs much like the current add_to_linker function.

This function would have the following signature:

/// Add component as a backing implementation to `linker`
///
/// The component will run against `store` and can have its own imports satisfied by `other_linker`
fn add_component_to_linker<T, U: Send + 'static>(
        linker: &mut Linker<T>,
        other_linker: &Linker<U>,
        other_store: Arc<Mutex<Store<U>>>,
        other_component: &Component,
) -> anyhow::Result<()>;

This signature would allow user's complete control over the linked other_component including the ability to turn on wasi support or even implement imports for that component. Unfortunately, the implementation needs other_store to be 'static and for it to be possible to get unique references to the underlying Store. If we want to allow multiple callers of add_component_to_linker to use the same other_store, that forces our hand to take Arc<Mutex<Store<U>>>.

The implementation would instantiate component against other_linker and other_store which would be moved inside the wrapped import of linker's root instance. When linker's wrapped import function gets called, the Store's mutex will be locked and the other_component instance will be called with the exact same arguments coming from the outer component.

Alternatives

The signature for add_component_to_linker is a bit awkward (especially due to taking a second linker). This is to maximize the user's ability to control the other_component instance. We could simplify the signature at the expense of this user control.

It's also possible for users to implement this without the help of wasmtime or the bindgen! macro; it's just fairly finicky code. While it would certainly be helpful for wasmtime to provide this functionality, it does not unlock new use cases that weren't possible before. Therefore, an alternative would be to just not do this.

view this post on Zulip Wasmtime GitHub notifications bot (Feb 20 2024 at 09:56):

BrytonLee commented on issue #7646:

I think this feature is needed. I am confused by the fn name add_to_linker and it blocks compiler as well. In my case, I want to include WASI support, thus newed a linker from wasmtime::Linker, suppose I can use wasmtime_wasi::add_to_linker() to enable WASI for engine, but I also want to use wasmtime::component to bindgen! my WIT file, wasmtime::component requires itself linker under wasmtime::component::Linker, althought both wasmtime_wasi and wasmtime::component use the same name add_to_linker, but they accept different linker types. Compiler wouldn't compile this code.

Rename wasmtime::component::add_to_linker to something else would definitely help, and I also sincely hope that wasmtime::component provides a fn to return a normal wasmtime::Linker instance that can be interacted with other part like wasmtime_wasi.

BTW: could you please share your insights if you know how to instantiate a wasmtime engine with both wasmtime_wasi and wasmtime::component support? Really appreciate.

Last updated: Nov 22 2024 at 17:03 UTC