Skip to content

Conversation

ADD-SP
Copy link
Member

@ADD-SP ADD-SP commented Jul 19, 2025

Review guide

Design document

See https://gist.github.com/ADD-SP/4037e25256b8dc8a4956962415de2356.

Benchmarks

See https://gist.github.com/ADD-SP/4037e25256b8dc8a4956962415de2356.

@ADD-SP ADD-SP added A-tokio Area: The main tokio crate M-time Module: tokio/time T-performance Topic: performance and benchmarks R-loom-time-driver Run loom time driver tests on this PR R-loom-current-thread Run loom current-thread tests on this PR R-loom-multi-thread Run loom multi-thread tests on this PR labels Jul 19, 2025
@ADD-SP ADD-SP changed the title [WIP] [WIP] time: delayed cancellation of timers Jul 19, 2025
@ADD-SP ADD-SP force-pushed the add_sp/time-local-wheel branch 11 times, most recently from c2d5790 to d04c22f Compare July 19, 2025 13:19
@ADD-SP ADD-SP changed the title [WIP] time: delayed cancellation of timers [WIP] time: delay the cancellation of timers Jul 19, 2025
}

#[tokio::test]
async fn reset_later_after_slot_starts() {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note

This test was removed because it was testing the behavior of tokio::runtime::time::entry::reset, which is removed in this PR.

}

#[tokio::test]
async fn reset_earlier_after_slot_starts() {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note

This test was removed because it was testing the behavior of tokio::runtime::time::entry::reset, which is removed in this PR.

sleep(ms(20)).await;

assert!(queue.is_woken());
assert_ready_some!(poll!(queue));
Copy link
Member Author

@ADD-SP ADD-SP Jul 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note

queue.reset_at resets inner Sleep, however, the new implementation will drop the inner timer and create a new one. So the waker will not be called, we have to poll manually.

sleep(ms(20)).await;

assert!(queue.is_woken());
assert_ready_some!(poll!(queue));
Copy link
Member Author

@ADD-SP ADD-SP Jul 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note

queue.reset_at resets inner Sleep, however, the new implementation will drop the inner timer and create a new one. So the waker will not be called, we have to poll manually.

Comment on lines +771 to +803
// runtime is shutting down
// OR waking up expired timers

// Track that a task was scheduled from **outside** of the runtime.
self.shared.scheduler_metrics.inc_remote_schedule_count();

// Schedule the task
self.shared.inject.push(task);
self.driver.unpark();
Copy link
Member Author

@ADD-SP ADD-SP Jul 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note

Since the wheel is stored in the Core, the cx.core is None while waking up timers.

While we could store Option in Core, this would double the number of possible states in the local time subsystem, which isn't worth it.

I know this creates some lock contention on the inject queue, but it doesn't shows the regression on the benchmark, so I kept it for now. Feel free to share your thought and possible optimization.

feature = "signal",
feature = "time",
))]
pub(crate) use wake_list::WakeList;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note

We no long use WakeList in the time subsystem.

Copy link
Contributor

@Darksonn Darksonn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry for taking long between reviewes, but this is a really large PR and I find it difficult to review. Here are a few things I noticed while looking at it, but I still don't feel like I have an overview.

Comment on lines 97 to 107
/// True if the driver is being shutdown.
is_shutdown: AtomicBool,

// When `true`, a call to `park_timeout` should immediately return and time
// should not advance. One reason for this to be `true` is if the task
// passed to `Runtime::block_on` called `task::yield_now()`.
//
// While it may look racy, it only has any effect when the clock is paused
// and pausing the clock is restricted to a single-threaded runtime.
#[cfg(feature = "test-util")]
did_wake: AtomicBool,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moving these atomics into their own Arc is best avoided. That's an allocation per integer, and they may be stored far away from each other hurting cache locality.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me revisit the shutdown process and relevant dataflows, will come back later.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate M-time Module: tokio/time R-loom-current-thread Run loom current-thread tests on this PR R-loom-multi-thread Run loom multi-thread tests on this PR R-loom-time-driver Run loom time driver tests on this PR T-performance Topic: performance and benchmarks
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants