Wasmtime GitHub notifications bot (Mar 03 2023 at 23:33): Wasmtime GitHub notifications bot (Mar 03 2023 at 23:33):dicej commented on issue #5925:
Note that I tried to modify the generated code for exports to decouple the resolve step from the call step (e.g. so you could do
(world.exports.get("x"))(&mut store)), and I had that working nicely in the non-async case, but the async case got really messy. I'll give it another shot next week.
Wasmtime GitHub notifications bot (Mar 03 2023 at 23:44):github-actions[bot] commented on issue #5925:
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>
Wasmtime GitHub notifications bot (Mar 05 2023 at 22:06):dicej commented on issue #5925:
After thinking about this some more, I realized that the "early vs. late resolution" tension I referred to above is not really a thing. Even if we force the host to do "early resolution" (i.e. prior to instantiating the component), it can just provide thunks which do asynchronous operations and/or trap at runtime if they need to. In other words, the host can always to "late resolution" (i.e. at the last possible moment, when called from the guest) inside the callback it provided at link time.
Anyway, I went ahead and rewrote this using an ultra-minimalist approach such that the binding generator just skips wildcards entirely, leaving the host to use dynamic APIs to reflect on the component and do the necessary
func_wrap(for imports) andtyped_func(for exports) calls directly. I'll close this and open a new PR.
Wasmtime GitHub notifications bot (Mar 05 2023 at 22:36):dicej commented on issue #5925:
See https://github.com/bytecodealliance/wasmtime/pull/5934 for the new PR.
Last updated: Dec 23 2024 at 13:07 UTC