Use a multi-threaded Tokio runtime as a fallback #8229
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit fixes a bug that was introduced in #8190 and brought up on Zulip. In #8190 there was a subtle change in how Tokio and the CLI are managed, namely that a Tokio runtime is installed at the start of the CLI to avoid entering/exiting the runtime on each blocking call. This had a small performance improvement relative to entering/exiting on each blocking call. This meant, though, that calls previously blocked with
Runtime::block_on
and now block withHandle::block_on
. The documentation ofHandle::block_on
has a clause that says that for single-threaded runtimes I/O and timers won't work.To fix this issue I've switch the fallback runtime to a multi-threaded runtime to ensure that I/O and timers continue to work.