Stream: wasmtime

Topic: ✔ Using wasmtime across Tokio tasks

Celarye (Aug 07 2025 at 20:45):

I have the following structs defined:

pub struct Runtime {
    plugins: HashMap<String, RuntimePlugin>,
}

pub struct RuntimePlugin {
    instance: Plugin,  // Auto-generated binding for my component instance.
    store: Store<InternalRuntime>,
}

struct InternalRuntime {
    ctx: WasiCtx,
    http: WasiHttpCtx,
    table: ResourceTable,
}

At the moment I share my Runtime across Tokio tasks by wrapping it in an Arc<Mutex<Runtime>>. But I would rather move the Mutex down to the stores so that I can make calls to multiple components concurrently:

pub struct RuntimePlugin {
    instance: Plugin,
    store: Mutex<Store<InternalRuntime>>,
}

And then call it like this:

pub async fn call_event(
    &self,
    plugin_name: &str,
    event: &DiscordEvents,
) -> Result<Vec<DiscordRequests>, ()> {
    let plugin = self.plugins.get(plugin_name).unwrap();

    match plugin
        .instance
        .discord_bot_plugin_plugin_functions()
        .call_discord_event(&mut plugin.store.lock().await, event)
        .await
    {
        Ok(call_result) => match call_result {
            Ok(discord_requests) => Ok(discord_requests),
            Err(err) => {
                error!("The plugin returned an error: {}", &err);
                Err(())
            }
        },
        Err(err) => {
            error!("Something went wrong while calling the plugin: {}", &err);
            Err(())
        }
    }
}

Though when I do this I run in a bunch of errors as it does not seem to like the Store<InternalRuntime> being wrapped in a MutexGuard:

error[E0277]: the trait bound `tokio::sync::Mutex<Store<InternalRuntime>>: AsContext` is not satisfied

It's also maybe worth to note that all Stores and component instances in the RuntimePlugin entries in the HashMap are created using the same Engine and Linker.

Is there some way to make this work?

Alex Crichton (Aug 07 2025 at 20:55):

I believe if you change &mut plugin.store.lock().await to &mut *plugin.store.lock().await (note the *) it should work

Alex Crichton (Aug 07 2025 at 20:56):

I'll note though that even if you do so you won't be making concurrent calls into wasm because you've still only got one Store<InternalRuntime> and that can only have one active execution of wasm at a time. If you want concurrent execution you'll likely want to create a Store-per-plugin

Celarye (Aug 07 2025 at 21:00):

My stores are already created per plugin so that won't be a limitation. And dereferencing the MutexGuard does solve it, thanks!

Notification Bot (Aug 07 2025 at 21:00):

Celarye has marked this topic as resolved.

Celarye (Aug 08 2025 at 17:30):

Just to clarify, is it okay for the different stores to reference the same Engine?

Alex Crichton (Aug 08 2025 at 17:34):

indeed! That's the main intended use case for engines/stores

Last updated: Dec 06 2025 at 06:05 UTC