You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Calling wasm functions requires a StoreMut<'_>. This leads to me having to wrap my wasm module in a Mutex<_> in order to get a mutable reference from it. This kinda sounds reasonable, since a module can modify its memory and thus needs exclusive access (and I can't run two functions in parallel from the same store).
In host functions, I get an impl AsStoreMut as the first parameter. This allows me to call wasm functions from inside the host function. This works fine, however:
If my host function calls another function that calls another function, the latter one doesn't have any idea that it's running inside a host function any more. If it wants to call a wasm function, it tries to lock the store again, because that's how it gets the store when it's called by someone else and that works fine. In these specific circumstances however, this leads to a deadlock, because the same thread tries to lock the same Mutex<_> again.
Every step on the way sounds reasonable, but in the context of the whole application, this causes a lot of problems. What I'm doing right now is to litter my code with Option<&mut StoreMut<'_>> parameters. If it's Some(_), use that one for calling wasm functions. If it's None, lock the store to get the mutable reference that way.
I don't have an easy solution, but this is highly annoying. I didn't have that architectural problem with wasmtime at all.
Additional details
The project I'm working on is proprietary and thus I can't show the code, but it's using this crate I created that contains the RwLock<_> in Context in context.rs.
The text was updated successfully, but these errors were encountered:
Summary
Calling wasm functions requires a
StoreMut<'_>
. This leads to me having to wrap my wasm module in aMutex<_>
in order to get a mutable reference from it. This kinda sounds reasonable, since a module can modify its memory and thus needs exclusive access (and I can't run two functions in parallel from the same store).In host functions, I get an
impl AsStoreMut
as the first parameter. This allows me to call wasm functions from inside the host function. This works fine, however:If my host function calls another function that calls another function, the latter one doesn't have any idea that it's running inside a host function any more. If it wants to call a wasm function, it tries to lock the store again, because that's how it gets the store when it's called by someone else and that works fine. In these specific circumstances however, this leads to a deadlock, because the same thread tries to lock the same
Mutex<_>
again.Every step on the way sounds reasonable, but in the context of the whole application, this causes a lot of problems. What I'm doing right now is to litter my code with
Option<&mut StoreMut<'_>>
parameters. If it'sSome(_)
, use that one for calling wasm functions. If it'sNone
, lock the store to get the mutable reference that way.I don't have an easy solution, but this is highly annoying. I didn't have that architectural problem with wasmtime at all.
Additional details
The project I'm working on is proprietary and thus I can't show the code, but it's using this crate I created that contains the
RwLock<_>
inContext
in context.rs.The text was updated successfully, but these errors were encountered: