Single-threaded async runtime

[HoKim98]

Feature

I want to use wasmtime in actix-web, which uses !Send runtime and resources such as HTTPRequest and web::Payload.

But the current runtime requires functions and states to be Sendable.

I thought it's not mandatory to enforce Send trait.
So I have tested on my local without Send and found no problem.

Benefit

We can use wasmtime in the thread-bounded (single-threaded) async runtimes.

It's essential to use wasmtime within actix ecosystem, which provides the input parameters as !Send.

Implementation

My current(initial) idea is to create buddy methods like below:

/// Original method
pub async fn instantiate_async(
    &self,
    mut store: impl AsContextMut<Data = T>,
) -> Result<Instance>
where
    T: Send,
{
    let mut store = store.as_context_mut();
    assert!(
        store.0.async_support(),
        "must use sync instantiation when async support is disabled"
    );
    store.on_fiber(|store| self.instantiate_impl(store)).await?
}

/// (New) buddy method
pub async fn instantiate_async_single_rt(
    &self,
    mut store: impl AsContextMut<Data = T>,
) -> Result<Instance> {
    let mut store = store.as_context_mut();
    assert!(
        store.0.async_support(),
        "must use sync instantiation when async support is disabled"
    );
    store
        .on_fiber_single_rt(|store| self.instantiate_impl_single_rt(store))
        .await?
}

• The estimated number of new lines: 100~500
• Side-effect: no

Alternatives

My another idea is to use cargo features like async-send.
But I think it may break the ecosystem (side-effect).

[pchickey]

Sorry - we have had this discussion in the past, and concluded that, with the current features available in the Rust type system, wasmtime's Send bounds are unfortunately infectious and will be used throughout the public API.

After maintaining wasmtime in tokio embeddings for many years, I'm now maintaining a single-threaded web server embedding for wasmtime where Send is a burden. Unfortunately I have solved this by adding a lot of blatantly false unsafe impl Send for <my types> {} throughout my codebase. But, we've balanced that against all of the known approaches to manage Send's infectiousness in wasmtime, and decided that its the best of the difficult options.

I won't rule out changing the design of wasmtime completely, but its a big project that requires a lot of time and attention from a skilled contributor, and will require a working prototype and RFC in order to land. If you are up for that project, lets talk about it more, but if not, we'll have to suffer together with the way it is now.

[HoKim98]

In my case, specifically when using the wasm32-wasip2 target (i.e., the version that doesn't explicitly depend on the tokio runtime), I haven't actually run into the issue you described.

In particular, I found that the core on_fiber method has evolved over the past year to the point where it has no real dependency on Send. That said, in environments like the tokio runtime where async tasks may be executed across threads, the "infectious" nature of Send often forces us to inject an otherwise void dependency.

To address this, I implemented buddy methods like the one that work correctly even in !Send environments. It's less of a new invention and more of a clone of the existing code adapted for !Send.

• ulagbulag@cfcd2c2

Finally, for types like trait Stream, the Send constraint isn't tied to the struct itself but to its implementation, which makes workarounds like unsafe impl Send for <my types> fundamentally impossible. While this is arguably a positive side effect of Send’s strictness, it also means we can’t bypass it even when we're sure the code will never leave the current thread.

Just to share a personal thought: I believe the implementation is fairly straightforward and easy to follow. A prototype is available at the link above, and buddy versions of the multi-stage test code are also planned. I’d love your take on whether you think this should go through an RFC, or if it’s fine to submit as a plain PR.