-
Notifications
You must be signed in to change notification settings - Fork 284
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow called host functions to execute Wasm functions via the wasmi::Engine
#572
Comments
We also rely on calling Wasm functions from within host function. Any chance this issue is on the roadmap? Thank you! |
Another +1 to this issue, we also rely on a pattern similar to what described in #567 (comment) , in which the Wasm module invokes a host function, and during its execution the host calls back into the Wasm module to perform an allocation. This is not a super common use case, but I have already seen a similar pattern in other projects as well, so I hope wasmi can prioritize and implement this. Thanks in advance! |
I will tag this issue with higher priority due to the following reasons:
|
I thought a bit about this issue and how we could implement it in
I am currently leaning towards 3) since it will be the superior solution and efficient for the common case. However, at this point I am hoping for a simpler alternative idea. |
To clarify, what we need is a way, while we are fulfilling an exported function call from Wasm to the host (let's call this "outer"), to be able to call back into the Wasm module (e.g. in order to perform an allocation) (let's call this "inner"). IIUC, neither of the two suggested options are ideal, since the inner call really needs to happen while the outer call is "waiting" (it cannot be done afterwards), and also it's not feasible to spawn a new Wasm engine, it needs to operate on the same Wasm instance that invoked the outer function. But I am not 100% sure. |
@tiziano88 All three design proposals are going to support your use case. Sorry if my write up was confusing to you. Maybe what confused you was the term "Wasm executor" which is different from the Proposal 1) does not go the full way in that it still provides only a single Wasm executor but allows to reuse that for sequentially consecutive Wasm function calls which would also support your use case but is more limited albeit simpler to implement. |
I wonder why the executor is locked when calling a function? If the calling and locking actions could be decoupled, we may achieve the goal. If they cannot be decoupled, we can set a global variable like |
Currently the Wasm executor is locked during the lifetime of a host call because of performance considerations. Unlocking before a host call and re-locking after a host call is inefficient and I was under the impression initially that host functions do not need to call back into the Wasm engine. If I knew better I had designed the system differently. My fault! So yeah: Basically proposal 1) is about shifting the lock so that the host call will happen outside of the lock. But as stated prior this is not an ideal solution and will still not support all use cases that Wasmtime currently supports. |
After researching the best possible kind of implementation I ended up choosing a rather simple approach to the problem. The PR for this issue is no longer WIP and there are only a few minor rough edges left to carve out before merging: #590 |
As stated in #567 it is currently not possible in
wasmi
to call Wasm functions from within called host functions due to a deadlock in theEngine
.We designed it this way because it was a simple implementation and we thought it was done similarly in Wasmtime, however, we were wrong about that since in Wasmtime it is possible to call Wasm functions from within called host functions as stated by the issue author.
Since we want to ideally mirror the Wasmtime functionality we want to implement this feature as well. The only downside is that it is slightly harder to implement since
wasmi
is an interpreter that has to carry arround all the execution state with each call stack. Therefore we need to implement a way to allow for multiple executors for a singlewasmi::Engine
.This issue tracks the progress of the feature.
The text was updated successfully, but these errors were encountered: