Expose epoch_deadline_callback in C++ api#11945
Expose epoch_deadline_callback in C++ api#11945alexcrichton merged 3 commits intobytecodealliance:mainfrom
Conversation
| if (!result) { | ||
| return result.err().release(); | ||
| } | ||
| *epoch_deadline_delta = |
There was a problem hiding this comment.
s/epoch_deadline_delta/update_kind/ I believe?
| store.epoch_deadline_callback( | ||
| [](wasmtime::Store::Context /* context */, uint64_t &epoch_deadline_delta) | ||
| -> wasmtime::Result<wasmtime::DeadlineKind> { | ||
| epoch_deadline_delta += 1; | ||
| return wasmtime::DeadlineKind::Continue; | ||
| }); |
There was a problem hiding this comment.
To help catch the above bug, would you be up for expanding the test her to run the callback as well?
There was a problem hiding this comment.
By the way, is there any reason why we should do epoch_deadline_delta += 1 in the callback instead of context.set_epoch_deadline(1) (the second does not work in the newly added test)?
There was a problem hiding this comment.
I believe it mostly mirrors the Rust-side API here. Other than that though no particular reasons, you're right that the Rust side could use the store to update the dealine and then return continue/yield as an enum.
vdimir
changed the title
| store.epoch_deadline_callback( | ||
| [](wasmtime::Store::Context /* context */, uint64_t &epoch_deadline_delta) | ||
| -> wasmtime::Result<wasmtime::DeadlineKind> { | ||
| epoch_deadline_delta += 1; | ||
| return wasmtime::DeadlineKind::Continue; | ||
| }); |
There was a problem hiding this comment.
I believe it mostly mirrors the Rust-side API here. Other than that though no particular reasons, you're right that the Rust side could use the store to update the dealine and then return continue/yield as an enum.
2 participants
Ref #6277