Stream: git-wasmtime

Topic: wasmtime / issue #7582 Parallel execution of the same WAS...

Wasmtime GitHub notifications bot (Nov 25 2023 at 11:43):

Photosounder opened issue #7582:

I've made a C host for WASM reactor modules using Wasmtime, the problem that I'm trying to solve is calling wasmtime_func_call() for the same instance of a WASM module simultaneously from two threads. For instance on my host's main thread I'll call a function of the WASM module to generate graphics while from an audio callback I'll call a function of the same instance of the same WASM module to generate sound.

The problem is that Wasmtime doesn't like this and after a few seconds of working correctly I either get a panic from Wasmtime or even a 0xC0000005: Access violation reading location from the host crashing.

Is there a known way to execute functions from the same WASM module instance in parallel? If not is there a way to have shared memory between two different instances of the same module using the C API?

Wasmtime GitHub notifications bot (Nov 27 2023 at 04:12):

alexcrichton commented on issue #7582:

A wasmtime_store_t cannot be shared across threads (although it can be sent between threads when it's not in use), so invoking two functions within the same instance/store is not safe and is undefined behavior. In theory the documentation covers this, but if it doesn't we should fix that! This would be a compile error in Rust, for example.

The closest approximation at this time is to use shared WebAssembly memories at this time. You'd create a single WebAssembly instance per thread (one store per thread), and all the instances would import a shared linear memory. This requires a lot of coordination in both the guest and the host at this time so it's a relatively advanced thing to do and requires a fair bit of knowledge of how everything works.

Wasmtime GitHub notifications bot (Nov 27 2023 at 11:13):

Photosounder commented on issue #7582:

Thank you, I didn't know this about how wasmtime_store_t works, but I just noticed that store.h says A store generally cannot be concurrently used. Will it always be like this?

It doesn't look like importing a shared memory is at all possible with the C API at the moment, that's rather limiting. However as far as I'm concerned that's ok, I can send commands to the host to fill any gap, I can create a command to do mutex-protected buffer synchronisation across instances, this is not optimal in terms of performance but at least that's foolproof and doesn't require anything sophisticated from Wasmtime nor WASI.

Wasmtime GitHub notifications bot (Nov 27 2023 at 15:09):

alexcrichton commented on issue #7582:

It's not planned to enable concurrent access within a wasmtime_store_t in the future, no. There are possible changes in upstream WebAssembly which might affect this but those are a long way away at this point.

Also yes the C API lags a bit behind the Rust API, so shared memories may not be exposed yet. If you'd like though a PR would be welcome to support shared memories in the C API.

Wasmtime GitHub notifications bot (Nov 29 2023 at 21:45):

alexcrichton closed issue #7582:

I've made a C host for WASM reactor modules using Wasmtime, the problem that I'm trying to solve is calling wasmtime_func_call() for the same instance of a WASM module simultaneously from two threads. For instance on my host's main thread I'll call a function of the WASM module to generate graphics while from an audio callback I'll call a function of the same instance of the same WASM module to generate sound.

The problem is that Wasmtime doesn't like this and after a few seconds of working correctly I either get a panic from Wasmtime or even a 0xC0000005: Access violation reading location from the host crashing.

Is there a known way to execute functions from the same WASM module instance in parallel? If not is there a way to have shared memory between two different instances of the same module using the C API?

Wasmtime GitHub notifications bot (Nov 29 2023 at 21:45):

alexcrichton commented on issue #7582:

I'm going to close this since I think the issue-at-hand has been answered, but if you have something you'd still like to discuss let me know and I can reopen.

Last updated: Nov 22 2024 at 16:03 UTC