Wasmtime GitHub notifications bot (Mar 20 2024 at 15:02): Wasmtime GitHub notifications bot (Mar 20 2024 at 15:02):alexcrichton requested fitzgen for a review on PR #8190.
Wasmtime GitHub notifications bot (Mar 20 2024 at 15:02):alexcrichton opened PR #8190 from alexcrichton:releive-tokio-overhead to bytecodealliance:main:
Currently all of Wasmtime's implementation of WASI is built on Tokio, but some operations are currently not asynchronous such as opening a file or reading a directory. Internally these use
spawn_blockingto satisfy the requirements of async users of WASI to avoid blocking the current thread. This use ofspawn_blocking, however, ends up causing mostly just performance overhead in the use case of the CLI, for example, where async wasm is not used. That then leads to this commit, implementing an opt-in mechanism to be able to block the current thread.A
WasiCtxnow has a flag indicating whether it's ok to block the current thread and that's carried to various filesystem operations that usespawn_blocking. The call tospawn_blockingis now conditional and skipped if this flag is set.Additionally the invocation point in the CLI for wasm modules is wrapped in a Tokio runtime to avoid entering/exiting Tokio in the "leaves" when wasm calls the host, as happens today. This hits a better fast path in Tokio that appears to be more efficient.
Semantically this should not result in any change for CLI programs except in one case: file writes. By default writes on
output-streamin WASI are asynchronous meaning that only one write can be in flight at a time. That being said all current users are immediately blocking waiting for this write to finish anyway, so this commit won't end up changing much. It's already the case that file reads are always blocking, for example. If necessary in the future though this can be further special-cased at the preview1 layer.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Mar 20 2024 at 15:02):alexcrichton requested wasmtime-core-reviewers for a review on PR #8190.
Wasmtime GitHub notifications bot (Mar 20 2024 at 15:26):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Mar 20 2024 at 15:26):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Mar 20 2024 at 15:26):fitzgen created PR review comment:
Might be kinda nice to wrap this dance into a helper method so that we don't have to check
self.allow_blocking_current_threadeverywhere and instead callself.spawn_blockingor something that internally either does a realspawn_blockingor runs the thing immediately on the current thread.
Wasmtime GitHub notifications bot (Mar 20 2024 at 20:34):alexcrichton updated PR #8190.
Wasmtime GitHub notifications bot (Mar 20 2024 at 20:34):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Mar 20 2024 at 20:34):alexcrichton created PR review comment:
Sounds good yeah, I did some refactoring to thread this through
Filewhich has a similar helper already.
Wasmtime GitHub notifications bot (Mar 20 2024 at 20:34):alexcrichton has enabled auto merge for PR #8190.
Wasmtime GitHub notifications bot (Mar 20 2024 at 21:16):alexcrichton merged PR #8190.
Last updated: Oct 23 2024 at 20:03 UTC