update oxide-tokio-rt to v0.1.4, tokio to v1.52.0#10272
Merged
Conversation
update `oxide-tokio-rt` to v0.1.4, `tokio` to v1.52.0 This branch updates our dependency on `oxide-tokio-rt` to pick up Tokio v1.52.0 and the corresponding changes to the default runtime settings in `oxide-tokio-rt`. In particular, this allows us to pick up two of my upstream fixes in Tokio for a pair of issues that have been major thorns in our side for some time: * Tokio PR tokio-rs/tokio#7431, released in [Tokio v1.51.0], changes the multi-threaded runtime to allow tasks in the LIFO slot to participate in work-stealing. Therefore, it should no longer be necessary to disable the LIFO slot optimization, as the pathology described in #8334, where a task placed in the LIFO slot can become permanently or semi-permanently stuck while the task that notified them runs for a long time without yielding, can no longer occur. `oxide-tokio-rt` v0.1.4 removes the runtime configuration to disable the LIFO slot as the issue has been fixed upstream. * Tokio PR tokio-rs/tokio#8010, released in [Tokio v1.52.0], which adds eager handoff for the I/O and time drivers in the multi-threaded runtime. This is currently an experimental feature, although it is your author's opinion that this is really a fix for incorrect runtime behavior. It changes worker threads in the multi-threaded runtime to wake another worker prior to polling tasks if that worker had previously been parked on the I/O driver or timer wheel. Eagerly handing off these resources should prevent pathologies such as #9619. `oxide-tokio-rt` v0.1.4 enables this behavior by default. Fixes #8334 Fixes #9619 [Tokio v1.52.0]: https://github.com/tokio-rs/tokio/releases/tag/tokio-1.52.0 [Tokio v1.51.0]: https://github.com/tokio-rs/tokio/releases/tag/tokio-1.51.0
Member
Author
|
Uh...did I do that? |
Member
Author
Yeah, that's definitely a flake, opened #10274 and will rerun. |
davepacheco
approved these changes
Apr 15, 2026
hawkw
added a commit
that referenced
this pull request
Apr 16, 2026
hawkw
added a commit
that referenced
this pull request
Apr 16, 2026
Commit #10272 updated our dependency on `oxide-tokio-rt` to v0.1.4 and our `tokio` dependency to v1.52.0. This allowed us to pick up two of my fixes for Tokio issues that have been a thorn in our side for a long time, tokio-rs/tokio#7431 and tokio-rs/tokio#8010, which fix #8334 and #9619, respectively. The nature of these fixes is described in greater detail in #10272. Unfortunately, #10272 had to be reverted (in #10279), since @iliana discovered an unrelated regression in Tokio v1.52.0, tokio-rs/tokio#8056 (our issue #10277). This regression caused `spawn_blocking` to occasionally hang, and was introduced in tokio-rs/tokio@1604bc3 (PR tokio-rs/tokio#7757). I've since reverted this change upstream (tokio-rs/tokio#8057), and published a patch release ([v1.52.1]), which fixes the regression. Therefore, it is now once again safe to update our Tokio dependency to pick up the other fixes. This commit does that. I've also confirmed that the issue described in #10277 is no longer present in Tokio v1.52.1, as demonstrated by the fact `cargo nextest run -p omicron-sled-agent --stress-count 100 -- --exact artifact_store::test::issue_7796` now succeeds without hanging once again. Fixes #10272
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 branch updates our dependency on
oxide-tokio-rtto pick up Tokio v1.52.0 and the corresponding changes to the default runtime settings inoxide-tokio-rt. In particular, this allows us to pick up two of my upstream fixes in Tokio for a pair of issues that have been major thorns in our side for some time:Tokio PR runtime: steal tasks from the LIFO slot tokio-rs/tokio#7431, released in Tokio v1.51.0, changes the multi-threaded runtime to allow tasks in the LIFO slot to participate in work-stealing. Therefore, it should no longer be necessary to disable the LIFO slot optimization, as the pathology described in Large number of stored certificates correlated with hanging API requests #8334, where a task placed in the LIFO slot can become permanently or semi-permanently stuck while the task that notified them runs for a long time without yielding, can no longer occur.
oxide-tokio-rtv0.1.4 removes the runtime configuration to disable the LIFO slot as the issue has been fixed upstream.Tokio PR runtime: optional eager I/O driver/timer handoff when polling tasks tokio-rs/tokio#8010, released in Tokio v1.52.0, which adds eager handoff for the I/O and time drivers in the multi-threaded runtime. This is currently an experimental feature, although it is your author's opinion that this is really a fix for incorrect runtime behavior. It changes worker threads in the multi-threaded runtime to wake another worker prior to polling tasks if that worker had previously been parked on the I/O driver or timer wheel. Eagerly handing off these resources should prevent pathologies such as Badly-behaved tokio task can wedge the runtime #9619.
oxide-tokio-rtv0.1.4 enables this behavior by default.Fixes #8334
Fixes #9619