Stream: wg-async-foundations

Topic: waker docs

simulacrum (Jul 26 2019 at 16:23, on Zulip):

I've been reading the Future and Waker docs in std, and AFAICT we're not documenting the exact spec for executors with regards to Waker. Specifically, what the effect of wake() on Waker is during different points of the execution model. I think there are several points that would be worth explicitly noting in the lifecycle.

For example, it's not clear what happens if code like this is written:

impl Future for MyType {
    type Output = ();
    fn poll(self: Pin<&mut Self>, cx: &mut Context) -> Poll<Self::Output> {
        return Poll::Pending;

Is this well behaved/reasonable code? Note that the wake call may happen on a separate thread, too, though that's not guaranteed. My expectation would be that this would work fine, and result in the future being polled indefinitely (i.e., essentially busy loop) but be guaranteed to not lead to recursion, that is no stack overflows.

simulacrum (Jul 26 2019 at 16:24, on Zulip):

(maybe this is also not the right place to discuss this -- though it feels like a pretty foundational question)

Taylor Cramer (Jul 26 2019 at 18:26, on Zulip):

Yes, that is well-behaved reasonable code.

Taylor Cramer (Jul 26 2019 at 18:26, on Zulip):

It will repeatedly cause the future of MyType to be polled in a loop

simulacrum (Jul 26 2019 at 22:48, on Zulip):

What are the expected effects of calling wake multiple times, prior to the poll method being called? Just one poll call? Multiple?

simulacrum (Jul 26 2019 at 22:49, on Zulip):

Along similar lines, the documentation notes that the _latest_ Waker must be used to initiate waking; when does the "new" waker become so? After entry into poll? Part of why I ask is to try to understand AtomicWaker -- and the use cases/need for it

simulacrum (Jul 26 2019 at 22:51, on Zulip):

It seems like the take method in particular is a bit odd to me, since I can't really think of how it can be used in a reasonable way -- wouldn't the new owner of the returned Waker not be able to tell whether it's the latest Waker? (My understanding is that AtomicWaker is purely for ensuring that separate threads which intend to call Wake can keep track of the latest waker for a given future -- but maybe that's wrong?)

Nemo157 (Jul 27 2019 at 12:29, on Zulip):

Calling wake multiple times I believe must lead to _at least_ one call to poll (which called also be said to be exactly one call to poll and some extra spurious wakeups)

Last update: Nov 18 2019 at 01:50UTC