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
{{ message }}
This repository has been archived by the owner on Jan 22, 2022. It is now read-only.
Hi. I'm further diving into wapc, and there're some very nice ideas in there! 😃
One thing I could not find so far is, are you able to stop a guest call of it's taking too much time? In wasmtime, you'd use the interrupt handle to set a trap, but I don't see why of that used here. What's your approach? 🤔
The text was updated successfully, but these errors were encountered:
The wapc host runtime (Rust) supports multiple engines, wasm3 and wasmtime. As such we can't support things like aborting an execution unless both engines support it.
That said, wasmcloud, which builds on top of wapc, does have time limits and can abort calls, It just doesn't use the wasm engine to do it.
Sure. If you take a look at wasmcloud in the wasmcloud host crate you'll see where we have a bunch of rpc timeouts.
That said, if a guest wasm spins into an infinite loop we do not currently have a way to shut that down gracefully, and we can use this issue to track that.
In short, the entire host will continue unbroken but that one module will be useless in that scenario and that's definitely something we need to take care of.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi. I'm further diving into wapc, and there're some very nice ideas in there! 😃
One thing I could not find so far is, are you able to stop a guest call of it's taking too much time? In wasmtime, you'd use the interrupt handle to set a trap, but I don't see why of that used here. What's your approach? 🤔
The text was updated successfully, but these errors were encountered: