Tracking Issue for LocalWaker

[tvallotton]

View all comments

Feature gate: #![feature(local_waker)]

This is a tracking issue for support for local wakers on Context. This allows libraries to hold non thread safe data on their wakers, guaranteeing at compile time that the wakers will not be sent across threads. It includes a ContextBuilder type for building contexts.

Public API

impl Context {
    fn local_waker(&self) -> &LocalWaker;
}

impl<'a> ContextBuilder<'a> {
   fn from_waker(waker: &'a Waker) -> ContextBuilder<'a>;
   fn waker(self, waker: &'a Waker) -> ContextBuilder<'a>;
   fn local_waker(self, local_waker: &'a LocalWaker,) -> ContextBuilder<'a>
   fn build(self) -> Context;
}

impl From<&mut Context> for ContextBuilder;

pub trait LocalWake {
    fn wake(self: Rc<Self>);
}

Steps / History

• Implementation:
  • Add LocalWaker and ContextBuilder types to core, and LocalWake trait to alloc. #118960
• Have the @rust-lang/wg-async approve the API
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• Should runtimes be allowed to not define a waker?

Relevant links

• Add LocalWaker support libs-team#191
• Context and Waker might be accidentally Sync #66481

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[tvallotton]

@zzwxh

If I don't intend to support cross-thread wake-ups, it's best not to force me to provide a dummy Waker that pretends to support cross-thread wake-ups.

I agree, it would be best if users could panic on the call to cx.waker() rather than in the call to waker.wake().

ContextBuilder should allow the asynchronous runtime to explicitly specify which type of Waker it supports (or both), and the Future should have the ability to retrieve this information.

The feature used to work exactly like this, offering a ContextBuilder::from_local_waker method, and a Context::try_waker method. However, too many concerns were raised about compatibility, and I decided that this was not a hill I was willing to die on. Note that it is still possible to reintroduce these methods in the future without breaking changes.

[Thomasdezeeuw]

Context::try_waker does not introduce breaking changes, and I don't understand what concerns anyone has. We just need to deprecate Context::from_raw and Context::waker and use the new API instead.

I'm not sure you know what you're saying here. "Just" deprecating a crucial API for all Futures is bad idea. It will break all existing Futures and creates massive churn.

[tvallotton]

@zzwxh

Context::try_waker does not introduce breaking changes

Yes, this is what I said.

We just need to deprecate Context::from_raw and Context::waker and use the new API instead.

No, Context::waker and Context::from_waker are still useful and should not be deprecated, even if we decide to support optional wakers.

[Thomasdezeeuw]

@zzwxh it's not ok that you deleted your comment. It's hard to read back a discussion that way.