Yield with defer queue

[Chaoses-Ib]

tokio has a yield_now() function that can be used to yield the current task. Because the task will be added to the back of the defer queue, it will be scheduled after other pending tasks (though not guaranteed to drive the driver). Is there any equivalent in Compio? Simply using something like the following will make the task be immediately polled again:

pub async fn yield_now() {
    YieldNow(false).await
}

struct YieldNow(bool);

impl Future for YieldNow {
    type Output = ();

    fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
        if !self.0 {
            self.0 = true;
            cx.waker().wake_by_ref();
            Poll::Pending
        } else {
            Poll::Ready(())
        }
    }
}

[Berrysoft]

There's no such one officially, but you have already implemented one:)

[AsakuraMizu]

Maybe you can use futures::pending!? Though it does not call wake.

[Chaoses-Ib]

There's no such one officially, but you have already implemented one:)

You're right. On a minimal example it works as expected. It turns out that the immediately polling behaviour I observed is actually because there are some sync syscalls. When these syscalls are issued, the scheduler will begin to poll the yielded task. But I only found some Windows GUI syscalls have this behaviour, std::thread::yield_now() and Sleep(1000) don't have any effect. I'm not sure if this is related to Winio. And is this the expected behaviour? Since these syscalls are sync, it's a bit surprising they will affect scheduling.

Maybe you can use futures::pending!? Though it does not call wake.

Yeah, the first I tried is futures::pending. Actually the above YieldNow is just futures::pending + wake_by_ref().

[Berrysoft]

If you want to sync the tasks, you have to use the sync primitives rather than controlling the runtime. The runtime of winio is affected by GUI event loop. It is rather complex.

[Berrysoft]

Here is the possible reason that why a sync method makes the runtime schedule: it might send a message to the event loop and calls the wndproc immediately. (Usually a SendMessage syscall does this.) The wndproc handles the message and calls runtime.run() immediately. It is intended behavior, because we want to response to the messages as soon as possible. Therefore it's an winio issue, and I think it's a feature rather than a bug:)

[Chaoses-Ib]

Oh, then this makes sense. SetWindowLong(GWL_STYLE) will indeed send a message. Though setting most properties also do, it feels a bit weird that syncly setting a property actually implies yielding.

Feel free to close this issue if adding yield_now() is not in the plan of Compio.

[Berrysoft]

I would recommend this one: https://docs.rs/embassy-futures/latest/embassy_futures/fn.yield_now.html

Although it's a new dependency, it's simple and may not increase the binary size a lot. As its implementation is the same as yours, I don't think we need to add yield_now here:)