Hi! Been fiddling with wasmtime recently, and had a small question about handling epoch deadlines.
I'm looking into using epochs for timing out long-running computations. One thing I'd quite like to support is "soft" timeouts - when the first deadline is hit, set a flag inside the running module (using an exported global or the like) and let the module handle the timeout. If it's still running after the second deadline is hit, then we should trap.
The obvious way to achieve this seems to be to add another case to EpochDeadline
which accepts a callback (of Fn(&mut StoreContextMut<T>) -> Result<()>
or similar). However, I don't think this approach is workable - just won't past muster with the borrow checker.
I don't know if there's any other way to go about adding a custom deadline handler? Not sure if what I'm trying to do is a good idea in the first place TBH!
Currently Store::new_epoch
is the one that synthesizes the Trap
, and I think we could implement your idea of a callback with that. I think instead we'd have to do something like FnMut(&mut T)
instead of StoreContextMut
, though. Would that work for your use case?
Yeah, &mut T
would be easier (and obviously mirrors what Store::limiter
does). In my particular case, I'm not sure it's sufficient though, as I'd quite like to modify the module's globals, which does require access to the store itself.
From a wasm-police perspective that probably isn't valid for an engine to do, because we would basically be arbitrarily modifying a global in the middle of wasm that it otherwise thinks is local to the module and not modified
e.g. something like binaryen could perhaps hoist a global.get
out of a loop thinking that the loop never modifies it, when in fact you could modify it in the middle through an embedder hook like this
Ahh, that makes sense, I did wonder. I guess it would be sufficient to receive a &mut
T then - I can just add an imported/external function to read that value from the store. I guess it's slightly slower than reading a global, but probably not enough I need to worry.
at the very least having an API like this would be more flexible than the current, would you be interested in making a PR for this new callback?
Yep, more than happy to put that together! Thanks for the information, that's very helpful :).
özkan gündoğan has marked this topic as resolved.
özkan gündoğan has marked this topic as unresolved.
özkan gündoğan has marked this topic as resolved.
özkan gündoğan has marked this topic as unresolved.
özkan gündoğan has marked this topic as resolved.
Last updated: Nov 22 2024 at 16:03 UTC