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.

Signed-off-by: ADD-SP [email protected]

@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.

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.

CARGO_TARGET_WASM32_WASIP1_RUNNER: "wasmtime run --"
CARGO_TARGET_WASM32_WASIP1_THREADS_RUNNER: "wasmtime run -W bulk-memory=y -W threads=y -S threads=y --"
RUSTFLAGS: --cfg tokio_unstable -Dwarnings -C target-feature=+atomics,+bulk-memory -C link-args=--max-memory=67108864
RUSTDOCFLAGS: -C link-args=--max-memory=67108864
Copy link
Member Author

@ADD-SP ADD-SP Oct 18, 2025

Choose a reason for hiding this comment

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

Note

/// let mut data = vec![0; 16 * 1024];

Comment on lines +918 to +920
let (core, ()) = self.enter_with_time_context(core, |time_cx| {
util::time::post_auto_advance(&handle.driver, auto_advance_duration);
util::time::process_expired_timers(&mut time_cx.wheel, &handle.driver);
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we avoid the RefCell like this?

  1. Obtain linked list of timers to wake up, while holding RefMut on core.
  2. Release RefMut on core.
  3. Iterate linked list to wake up tasks, without RefMut.

Comment on lines +872 to +877
util::time::remove_cancelled_timers(&mut time_cx.wheel, &mut time_cx.canc_rx);
let should_yield = util::time::insert_inject_timers(
&mut time_cx.wheel,
&time_cx.canc_tx,
handle.take_remote_timers(),
);
Copy link
Contributor

Choose a reason for hiding this comment

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

For cancellation, we probably also have to move timers to linked list, and cancel after releasing RefMut. (I think.)

Comment on lines +1329 to +1334
pub(crate) fn push_remote_timer(&self, hdl: EntryHandle) {
{
let mut synced = self.shared.synced.lock();
synced.inject_timers.push(hdl);
}
self.notify_parked_remote();
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we should use a different mutex from task injectoin queue for contention?

/// The entry is in the pending queue of the timer wheel,
/// and not in any wheel level, which means that
/// the entry is reached its deadline and waiting to be woken up.
Pending(Sender, Waker, ThreadId),
Copy link
Contributor

Choose a reason for hiding this comment

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

Since block_in_place may move the Core from one thread to another, using the thread id may be a problem.

}
}

pub(crate) fn register_waker(&self, waker: &Waker) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Consider dropping old waker after releasing lock.

Comment on lines +59 to +65
if thread_id == cur_thread_id {
// Safety:
// 1. entry is either in slots or pending list
// 2. entry is registered in this thread
unsafe {
wheel.remove(entry);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we can just call entry.transition_to_cancelling() always here to avoid relying on thread id?

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.

3 participants