Tracking Issue for task::Waker::noop

[SabrinaJewson]

Feature gate: #![feature(noop_waker)]

This is a tracking issue for task::Waker::noop, a way to easily crate task::Wakers that do nothing.

Public API

// core::task

impl Waker {
    #[must_use]
    pub const fn noop() -> &Waker { /* … */ }
}

Steps / History

• Implementation: Add task::Waker::noop #96875
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Should we also add RawWaker::noop()? (I don't think so, I can't think of a use case for it)
• Should we also add Context::noop()? Depending on the direction Context goes a “noop context” might not even make sense in future.
• Should it be an associated constant instead? That would allow for let cx = &mut Context::from_waker(&Waker::NOOP); to work on one line (without additional local variables) which is convenient.
  • The return type of Waker::noop() has now been changed to &Waker.

[JarredAllen]

+1 on this feature, I find myself re-implementing a noop Waker frequently.

As for the third question, I'd personally prefer either an associated constant or changing the return signature to fn noop() -> &'static Waker;, because the only use I have for it involves immediately shoving it into Context::from_waker, which is more convenient with either of those signatures, though I'm not sure if other people have other use cases that are made easier by a function returning an owned value.

[traviscross]

@rustbot labels +I-async-nominated

Let's discuss this in a WG-async meeting as this has come up in the context of #101196.

[yoshuawuyts]

Speaking just for myself here: to me this seems generally useful as a utility, somewhat akin to future::pending and iter::empty. But I wonder whether instead of exposing it as a method on Waker, it might make more sense to create a new free function for it? That would place it a bit off the hot path, and more in the utilities section.

This would basically be a shorthand for creating a waker from Arc via the Wake trait, but minus a bit of overhead when cloning it.

[traviscross]

We discussed this in the WG-async triage call today. While everyone did see use cases for this, some also had concerns about this potentially being misused. E.g. someone might use this when the person should instead call .await. No-one seemed to think that was a blocker by itself ("Rust has lots of hard things"). Some were also unsure whether this was worth it and whether the cost of duplicating this code might actually induce a useful friction.

We were curious to hear more about the use cases. If people here could help to fill in the details of the various use cases for this, that would help with discussion, and it may help enable a WG-async consensus to form.

[Ralith]

A use case today, from quinn: I want to send a UDP datagram if doing so would succeed immediately, or otherwise drop the datagram entirely, because it's a response to a cheap request I know the peer will retry. It'd be convenient to be able to express this through a normal async UDP socket interface.

[kpreid]

Two use cases that I've come across:

• Running a Future concurrently with some other, much heavier, loop (where the output of the future would tell it to stop or otherwise give it relevant input, or the future needs to always be run in some particular context or with particular timing relative to the other work), where polling the Future unnecessarily is insignificant relative to the other work being done, so it isn't worth bothering implementing a wakeup.
  • But in this scenario, it might be better to provide a generic Future wrapper which internally provides a Waker in order to exit early if polled early, and itself presents poll_without_a_waker() to its owner.
• Running a Future, starting from a synchronous context, that we know won't actually return Pending, because it came from generic async code but contains no leaf futures that suspend.
  • This can be done instead with a block_on(), but that requires more code than needed bringing in synchronization primitives until such time as we get LocalWaker, and it could hide bugs where the future does suspend and we'd rather panic about it.
  • But now_or_never() is a simpler to use, narrower function for that. Notably, it doesn't require pinning the future.

But I've reached for futures::task::noop_waker_ref() more times than that, for reasons I don't recall in detail — probably experiments and code that eventually got replaced. So, even though I just listed a bunch of alternatives, I think there should be a noop Waker readily available, because there's a bunch of things you might want to do quickly and then later replace with something more refined.

---

Separately: I notice that one of the unresolved questions is:

Should it be an associated constant instead? That would allow for let cx = &mut Context::from_waker(&Waker::NOOP); to work on one line (without additional local variables) which is convenient.

I think that either this, or providing the equivalent of noop_waker_ref(), is a good idea. Either way you can always get an owned waker with .clone(), but it's not so convenient to create a reference given an owned waker. (And someone might come up with a use for a Context<'static>, which can't be made from an owned value without Box::leak().)

And in 100% of the cases I've ever used a noop waker, I used noop_waker_ref(), not the owned version noop_waker(). (But I haven't written any future combinators or other code that I imagine might be interested might be want to use an owned noop waker as a placeholder value in a data structure, as opposed to immediately creating a Context which only wants a reference.)

[jkarneges]

+1 for something that can provide a reference.

For me, a noop waker is mainly interesting for tests or experimentation/playground, and enabling another line of code to be saved seems within the spirit of that. I don't know if I've ever needed an owned noop waker, and as kpreid suggests can just clone() if that ever happens.

No opinion on constant vs function.

[kpreid]

I prepared a change which replaced Waker::noop() with Waker::NOOP. Unfortunately, it seems that this doesn't enable &NOOP usage:

let mut cx = &mut Context::from_waker(&Waker::NOOP);
cx.waker().wake_by_ref();

error[E0716]: temporary value dropped while borrowed
   --> src/wake.rs:404:44
    |
404 |     let mut cx = &mut Context::from_waker(&Waker::NOOP);
    |                                            ^^^^^^^^^^^ - temporary value is freed at the end of this statement

If I understand correctly now, this is not possible because the Waker has a destructor. Therefore, since use via constant promotion is not possible, it seems wise to offer a &Waker value, in which case making it a constant rather than a const fn doesn't provide any advantages (but still might be a choice of API aesthetics).

[traviscross]

In the WG-async call today, we discussed this, resulting in the following consensus:

Consensus: WG-async is in favor of returning &Waker from the function (as in #119984) due to ergonomic considerations related to const promotion and temporary lifetimes. We're OK with the Waker::noop() name for this function since we expect this is what people will need most of the time, and if we later did find that people needed an owned no-op waker (for reasons we can't imagine today) that it could receive the longer name, e.g. Waker::noop_owned. In our discussions, we did wonder about whether it would also make sense to add Context::noop() (which would return an owned Context) which would shorten the most common use-case further.

[kpreid]

@traviscross Does WG-async have any opinion about the question of making it be Waker::NOOP, a constant instead of a function? Per this Zulip discussion it's very rare across std for constant values to be provided as functions rather than constants (except for new() functions).

[traviscross]

@kpreid: You raise a good question about whether this should instead be a const. We'll be sure to discuss that at the next WG-async triage meeting.

[traviscross]

We discussed this in the WG-async call today. Our consensus was:

WG-async is in favor of this being an associated constant of type &Waker.

Thanks for @kpreid for raising this point.

As far as why it should be of type &Waker rather than Waker, it's due to code such as this:

pub const NOP_CONTEXT: Context<'static> =
    Context::from_waker(&Waker::NOOP);
//~^ ERROR destructor of `Waker` cannot be evaluated at compile-time
//~| NOTE the destructor for this type cannot be evaluated in constants
//~^ ERROR temporary value dropped while borrowed
//~| creates a temporary value which is freed while still in use

If the constant has type &Waker, then that code works.

[kpreid]

For cross-reference, and @traviscross FYI, I opened #122924 to implement the change to a constant, and I got an objection from @joboet on the grounds that

Constants are used when we actually care about the specific value in question (so you could e.g. match on it), not just about its semantics. Hence e.g. ONCE_INIT was deprecated in favour of Once::new(). Here, we don't care about the specific vtable or pointer used, and wouldn't care if they changed across calls to Waker::noop, as long as the resulting Waker obeyed the rules outlined by the documentation.

[traviscross]

Replied to that here with further discussion continuing there.

[kpreid]

T-libs-api and myself discussed the question of Waker::noop() vs. Waker::NOOP. One of the things that we noticed is that there is no value in providing a constant for comparison purposes, because Waker isn't PartialEq, let alone StructuralPartialEq. Rather, it provides the will_wake() function, which is equally applicable regardless of what API is chosen for the noop waker. So, I'm personally not going to pursue changing it to a constant NOOP, and would be happy to see this stabilized in its current form: const fn noop() -> &'static Waker. (More commentary on the PR.)

[jkarneges]

to me this seems generally useful as a utility, somewhat akin to future::pending and iter::empty. But I wonder whether instead of exposing it as a method on Waker, it might make more sense to create a new free function for it?

Apologies for further bikeshedding on this smallest of features, but was this form ever considered? I kind of like std::task::noop_waker, as it's probably what would have been proposed if Waker were a trait, and Waker is pretty much a trait in spirit.

Either way, what's left? FCP?

[JoJoJet]

Looking forward to this feature. I just noticed that the documentation for Waker::will_wake asserts that two wakers are guaranteed to wake the same task if will_wake returns true. I think that this function violates that assertion which should probably be considered

I think that the current behavior of will_wake is probably reasonable but it might be good to rephrase that guarantee

[kpreid]

The thing is that the entire concept of “task” is not formally defined (given various possible executors and combinators; e.g. Shared causes a future to potentially be polled by many different parent tasks; is that itself a task?) and irrelevant to implementing a Future. The only thing that actually matters is that a Future eventually signals its Waker when it is able to make progress, and the Future will be eventually polled or dropped after it signals its Waker. So, relying on anything about “task” identity is a bad idea whether or not Waker::noop() exists.

“Task” is basically “ownership of a Future being driven to completion”, and similarly to ordinary ownership, you can't point at any single type or language construct and say “this is an owner” or “this is a task”; you can only say:

• This value should be dropped when it is no longer in use, and no sooner than that.
  How is that implemented? That's the owner.
• This Future should be polled when it wakes, and ideally not when it doesn't.
  How is that implemented? That's the task.

In this frame, Waker::noop() is a degenerate case of “task” in much the same way as Box::leak() is a degenerate case of ownership: there are no entities in the program which are playing the role of task or owner, but that doesn't matter because the necessary rules are followed anyway. We could say that polling with Waker::noop() makes the future part of “the noop task”, if we like; there's nothing concrete to point at to contradict the existence of such a task.

[JoJoJet]

So, relying on anything about “task” identity is a bad idea whether or not Waker::noop() exists.

I don't necessarily disagree, but the whole point of will_wake is to let you reason about task identity. I don't think this is a major problem, but for correctness sake it would make sense to weaken that guarantee, since it doesn't really guarantee anything. will_wake is already described as a "best effort", so it would be good to document that there are degenerate cases where the concept of task identity falls apart

[kpreid]

I don't necessarily disagree, but the whole point of will_wake is to let you reason about task identity.

As I see it, the whole point of will_wake is to let you short-circuit some mutation and cloning if you already have an acceptable waker. But, we should probably not continue having this argument on a tracking issue, as it clutters the thread with things that aren't status updates on Waker::noop(), and notifies people who don't care. Perhaps you could file a separate issue for this documentation/semantics concern? (I'm presuming it's unlikely to imply any changes to what Waker::noop() actually does or is named.)

[JoJoJet]

I'm not arguing, just sharing concerns :)

[ijackson]

I wanted a no-op waker for an exciting future I'm writing. I ended up implementing my own, of course.

I also noticed the possibility for misuse, and there was some confusion amongst some of my colleagues. I thought it best to document when not to use this, and made #128064 for that.

It would be nice to see this stabilised in some form, even if only to give those docs more exposure.

[c410-f3r]

#128064 was merged so can we proceed with the stabilization of Waker::noop? AFAICT, the addition of RawWaker::noop() or Context::noop() is orthogonal.