github-actions[bot] commented on Issue #2822:
Subscribe to Label Action
cc @peterhuene
<details>
This issue or pull request has been labeled: "wasmtime:api"Thus the following users have been cc'd because of the following labels:
- peterhuene: wasmtime:api
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
peterhuene commented on Issue #2822:
I wonder if we should be invoking
init_traps
automatically when we're about to resume a fiber inside of the async machinery just in case the future moved threads. It would reduce the use case of this to only times when users explicitly move aStore
and related components to another thread.
bnjbvr commented on Issue #2822:
It's a good point, and in fact it's already done automatically by wasmtime after resuming from a suspended fiber: https://github.com/bytecodealliance/wasmtime/blob/main/crates/runtime/src/traphandlers.rs#L436
Your remark makes me notice that this new API would also create a double standard: the runtime may automatically manage switching to a different thread in one case (async import causing wasm execution resuming on a different thread) when in another case one has to explicitly call the new API. The ubiquity of multithreaded future executors makes it justified in my opinion, but that's open to discussion!
alexcrichton commented on Issue #2822:
Thanks for this! I agree that it's a little odd that this might automatically happen as part of a future execution but then it doesn't automatically happen otherwise, but I agree that it's probably ok for now. Can you add documentation about this function on the multithreading page and also link the documentation on this function to the multithreading page?
bnjbvr commented on Issue #2822:
Done, thanks!
Last updated: Dec 23 2024 at 13:07 UTC