Expose TrapCode::Interrupt on epoch based interruption
#4105
Conversation
saulecabrera
force-pushed
the
expose-trap-code-on-epoch-interruption
branch
from
95ade38
to
9b06286
Compare
|
Using the |
saulecabrera
force-pushed
the
expose-trap-code-on-epoch-interruption
branch
from
9b06286
to
8d94f5b
Compare
|
Thanks for the feedback @alexcrichton! I agree, that's a much cleaner solution, I had overlooked this approach due a misunderstanding in the relationship between |
| @@ -1856,7 +1856,14 @@ unsafe impl<T> wasmtime_runtime::Store for StoreInner<T> { | |||
|
|
|||
| fn new_epoch(&mut self) -> Result<u64, anyhow::Error> { | |||
| return match &self.epoch_deadline_behavior { | |||
| &EpochDeadline::Trap => Err(anyhow::Error::new(EpochDeadlineError)), | |||
| &EpochDeadline::Trap => { | |||
| let trap = Trap::new_wasm( | |||
There was a problem hiding this comment.
It seems that this call could be simplified in this case by exposing a Trap::from_trap_code function in the Trap implementation, which would take in the TrapCode and apply the corresponding defaults for the pc and backtrace.
Didn't introduce this change right away since this is the only use case but I can totally do it if you think it's worth it.
There was a problem hiding this comment.
This seems reasonable enough to me for now, if this pops up more often we can make a helper for it
github-actions
bot
added
the
wasmtime:api
Subscribe to Label Actioncc @peterhuene
This issue or pull request has been labeled: "wasmtime:api"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
| @@ -1856,7 +1856,14 @@ unsafe impl<T> wasmtime_runtime::Store for StoreInner<T> { | |||
|
|
|||
| fn new_epoch(&mut self) -> Result<u64, anyhow::Error> { | |||
| return match &self.epoch_deadline_behavior { | |||
| &EpochDeadline::Trap => Err(anyhow::Error::new(EpochDeadlineError)), | |||
| &EpochDeadline::Trap => { | |||
| let trap = Trap::new_wasm( | |||
There was a problem hiding this comment.
This seems reasonable enough to me for now, if this pops up more often we can make a helper for it
I had a discussion via Zulip with @alexcrichton about this change. I decided to expose the
TrapCodeinstead of the private error (EpochDeadlineError) mainly to keep the same behaviour as the deprecated InterruptHandle approach.