Stream: git-wasmtime

Topic: wasmtime / PR #8190 Implement opt-in for enabling WASI to...


view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2024 at 15:02):

alexcrichton requested fitzgen for a review on PR #8190.

view this post on Zulip 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_blocking to satisfy the requirements of async users of WASI to avoid blocking the current thread. This use of spawn_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 WasiCtx now has a flag indicating whether it's ok to block the current thread and that's carried to various filesystem operations that use spawn_blocking. The call to spawn_blocking is 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-stream in 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:

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2024 at 15:02):

alexcrichton requested wasmtime-core-reviewers for a review on PR #8190.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2024 at 15:26):

fitzgen submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2024 at 15:26):

fitzgen submitted PR review.

view this post on Zulip 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_thread everywhere and instead call self.spawn_blocking or something that internally either does a real spawn_blocking or runs the thing immediately on the current thread.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2024 at 20:34):

alexcrichton updated PR #8190.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2024 at 20:34):

alexcrichton submitted PR review.

view this post on Zulip 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 File which has a similar helper already.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2024 at 20:34):

alexcrichton has enabled auto merge for PR #8190.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 20 2024 at 21:16):

alexcrichton merged PR #8190.


Last updated: Dec 23 2024 at 12:05 UTC