Override Waker::clone_from to avoid cloning Wakers unnecessarily

[SabrinaJewson]

This would be very useful for futures — I think it’s pretty much always what they want to do instead of *waker = cx.waker().clone().

Tracking issue: #98287

r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[JohnTitor]

Could you add a tracking issue here as well?

[JohnCSimon]

triage:

Could you add a tracking issue here as well?

@SabrinaJewson ☝️

[SabrinaJewson]

I think I did that already.

[a1phyr]

I think that overriding Clone::clone_from would be preferable over adding a new method.

I agree that it is less discoverable though.

[SabrinaJewson]

That is a very good point, I forgot that method existed. I think I will change this PR to implement that instead — a note in the documentation would probably be sufficient.

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[conradludgate]

Semi-related to this PR. Should Arc get a similar impl?

[pitaj]

@joshtriplett ping from triage, no movement for 4 months. What's the status of this PR?

@SabrinaJewson FYI you may need to squash your commits

[workingjubilee]

Please rebase to remove the master-merge.

r? @workingjubilee
@rustbot author

This looks plausible, but I have one question: Are we sure it's okay to elide the possible clone effect?
https://github.com/rust-lang/rust/blob/834ed29b5882a20c5399a85cd7ff443ef0d03f91/library/core/src/task/wake.rs#L81-L90

[coolreader18]

Unsure if it'd make sense to do this here or another PR, but it might be good to add docs here to aid discoverability (I believe rustdoc pops open trait impls by default when an associated item has docs? or at least it'll catch the eye when scanning the page), and also especially since the will_wake docs link here. I can't remember it off the top of my head, but I'm almost certain there's prior art in the standard library of adding docs to associated items of an impl.

[workingjubilee]

I think we can handle that in a followup. It might be a good idea to doc ~all the overridden clone_froms in std as a single PR.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[dtolnay]

@bors r=workingjubilee

[bors]

📌 Commit 6cdb7df has been approved by workingjubilee

It is now in the queue for this repository.

[bors]

⌛ Testing commit 6cdb7df with merge fee5518...

[bors]

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing fee5518 to master...

[rust-timer]

Finished benchmarking commit (fee5518): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.3%	[-0.3%, -0.3%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.3%	[-0.3%, -0.3%]	1

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.5%, 0.9%]	3
Regressions ❌ (secondary)	0.7%	[0.7%, 0.7%]	1
Improvements ✅ (primary)	-0.5%	[-0.6%, -0.4%]	4
Improvements ✅ (secondary)	-4.3%	[-4.3%, -4.3%]	1
All ❌✅ (primary)	-0.0%	[-0.6%, 0.9%]	7

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.5%, 0.6%]	3
Regressions ❌ (secondary)	2.6%	[2.6%, 2.6%]	1
Improvements ✅ (primary)	-0.5%	[-0.6%, -0.4%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[-0.6%, 0.6%]	6

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 637.169s -> 636.185s (-0.15%)
Artifact size: 304.52 MiB -> 304.50 MiB (-0.01%)

[wiseaidev]

Hey friends. I am trying to understand the practicality of this feature. Let's consider the following example:

use std::task::{Context, Poll, Waker};
use std::pin::Pin;
use futures::task::noop_waker_ref;

#[derive(Debug, Clone)]
struct MyTask {
    id: usize,
}

struct MyFuture {
    waker: Waker,
    task: MyTask,
}

impl MyFuture {
    fn new(id: usize) -> Self {
        let task = MyTask { id };
        let waker = noop_waker_ref();
        MyFuture { waker: waker.clone(), task }
    }
}

impl futures::Future for MyFuture {
    type Output = ();

    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
        let cloned_waker = self.waker.clone();
        println!("Cloned Waker address: {:?}", &cloned_waker as *const Waker);

        // `clone_from` used here
        //  Note: `Waker::clone_from(cx.waker(), &self.waker)` returns
        //         ----------------- ^^^^^^^^^^ types differ in mutability
        //                               |
        //                               arguments to this function are incorrect
        //
        // = note: expected mutable reference `&mut Waker`
        //              found reference `&Waker`
        let mut optimized_waker = cx.waker().clone_from(&&self.waker);
        println!("Optimized Waker address: {:?}", std::ptr::addr_of!(optimized_waker));

        Poll::Ready(())
    }
}

fn main() {
    // Create two MyFuture with the same task ID
    let my_future1 = MyFuture::new(42);
    let my_future2 = MyFuture::new(42);

    let mut pinned1 = Box::pin(my_future1);
    let mut pinned2 = Box::pin(my_future2);

    // Create a dummy Context
    let mut cx = Context::from_waker(&noop_waker_ref());

    // Poll the futures
    let _result1 = futures::Future::poll(pinned1.as_mut(), &mut cx);
    let _result2 = futures::Future::poll(pinned2.as_mut(), &mut cx);
}

This would result with the following being displayed on the terminal:

Cloned Waker address: 0x7fffaf9e6538
Optimized Waker address: 0x7fffaf9e6597
Cloned Waker address: 0x7fffaf9e6538
Optimized Waker address: 0x7fffaf9e6597

As evident from the output, both 'Cloned Waker' and 'Optimized Waker' share identical addresses for each corresponding pair. This suggests that the clone_from optimization does not trigger any difference in terms of memory addresses. Therefore, I am currently pondering how this feature might be beneficial for end users.

Any additional info about this feature would be appreciated. Thanks!

[SabrinaJewson]

There are a couple of issues here. Firstly, you have the argument order the wrong way round: a.clone_from(b) will set a to the (cloned) value of b, not the other way around. Therefore, since futures need to store cx.waker() inside the future itself for later use, in your function you should write self.waker.clone_from(cx.waker()); (and correspondingly self.waker = cx.waker().clone()). The current code only clones a reference to a waker, which is useless because it’s Copy anyway.

Secondly, using addr_of! on a &Waker will only retrieve the address of the local variable holding the waker. But this isn’t important to you at all — what matters is the interior pointer held by the waker. The Debug implementation of the waker should print this.

Thirdly, cloning the noop_waker_ref() will be a noöp anyway, because the noöp waker holds no state, and so there is nothing to be gained by using this optimization to avoid cloning it. The interior address will be the null pointer in both cases, which you can verify by running the version of your code with the two above issues fixed.

Even when one builds a waker via the Wake trait, the difference is not observable, since the effect is the same:

• Without clone_from, the Arc’s reference count is incremented, but then immediately decremented;
• With clone_from, the Arc’s reference count remains constant.

To test this feature properly, you thus have to make a custom waker that performs some sideëffect on clone and/or drop. You can see in the output of this program does not clone in the clone_from sections.

[wiseaidev]

Thanks for the clear explanation @SabrinaJewson! That's really helpful. I tried your example on both 1.74 and 1.75, and noticed the following optimization being done in this PR:

First poll:
With `clone`:
cloning
waker is Waker { data: 0x0, vtable: 0x55fc7102d140 }
With `clone_from`:
- cloning
- dropping
waker is Waker { data: 0x0, vtable: 0x55fc7102d140 }
Second poll:
With `clone`:
cloning
dropping
waker is Waker { data: 0x0, vtable: 0x55fc7102d140 }
With `clone_from`:
- cloning
- dropping
waker is Waker { data: 0x0, vtable: 0x55fc7102d140 }
dropping
dropping

So, clone_from would avoid redundant cloning and drooping each time being called unlike the case of clone. nice!