Skip to content

update oxide-tokio-rt to v0.1.4, tokio to v1.52.0#10272

Merged
hawkw merged 1 commit intomainfrom
eliza/oxide-tokio-rt-1.52
Apr 15, 2026
Merged

update oxide-tokio-rt to v0.1.4, tokio to v1.52.0#10272
hawkw merged 1 commit intomainfrom
eliza/oxide-tokio-rt-1.52

Conversation

@hawkw
Copy link
Copy Markdown
Member

@hawkw hawkw commented Apr 15, 2026

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:

Fixes #8334
Fixes #9619

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
@hawkw hawkw self-assigned this Apr 15, 2026
@hawkw
Copy link
Copy Markdown
Member Author

hawkw commented Apr 15, 2026

Uh...did I do that?

@hawkw
Copy link
Copy Markdown
Member Author

hawkw commented Apr 15, 2026

Uh...did I do that?

Yeah, that's definitely a flake, opened #10274 and will rerun.

@hawkw hawkw merged commit 5c0b62d into main Apr 15, 2026
18 checks passed
@hawkw hawkw deleted the eliza/oxide-tokio-rt-1.52 branch April 15, 2026 23:48
hawkw added a commit that referenced this pull request Apr 16, 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Badly-behaved tokio task can wedge the runtime Large number of stored certificates correlated with hanging API requests

2 participants