tokio::task::yield_now() is not completely yields and fetch never completes

[gzp79]

Description
See the provided code sample.
When tokio yield_now is used, the fetch_with_request never resolves. Both loop performs a few steps but fetch_with_request never completes when yield_now is used (The Fetching... is logged, but unreachable is never reached). If I replace it with wasm_timer::Delay with a 0 Duration, the fetch works as expected and the download completes with either success or error.

The error was originally reported in for tokio but it seems as this is the correct place to report/ask.

use wasm_bindgen_futures::JsFuture;
use web_sys::{Request, RequestInit, RequestMode};
use wasm_bindgen_test::wasm_bindgen_test as test;

#[test]
async fn yield_bug() {
    wasm_logger::init(::wasm_logger::Config::new(log::Level::Trace));
        
    wasm_bindgen_futures::spawn_local(async move {
        let mut i = 0;
        loop {
            let mut opts = RequestInit::new();
            opts.method("GET");
            opts.mode(RequestMode::Cors);
            let url = "https://example.com";
            let request = Request::new_with_str_and_init(&url, &opts).unwrap();

            let window = web_sys::window().unwrap();
            log::trace!("Fetching... {}", i);
            match JsFuture::from(window.fetch_with_request(&request)).await {
                Ok(_) => log::trace!("OK {}", i),
                Err(_) => log::trace!("ERROR {}", i),
            };            
            i += 1;

            unreachable!("For some reason we never get here with tokio::task::yield_now()");
        }
    });

    loop {
        let mut i = 0;
        loop {
            if i % 100000 == 0 {
                log::trace!("CC {}", i);
            }
            tokio::task::yield_now().await;
            //let _ = wasm_timer::Delay::new(std::time::Duration::from_micros(0)).await;
            i += 1;
        }
    }
}

[hamza1311]

tokio::task::yield_now's documentation says:

Yields execution back to the Tokio runtime.

Your is not running in a Tokio runtime. wasm_bindgen_futures::spawn_local is effectively a wrapper around new Promise(...). You can't use Tokio runtime specific function while running a JS promise

[gzp79]

Thanks. In that case is there some similar "yield" feature ? wasm_timer could be an option, but that crate seems to be not maintained any more and the latest release has some issue: tomaka/wasm-timer#14

[acheroncrypto]

fluvio-wasm-timer works for this.

[gzp79]

fluvio-wasm-timer works for this.

Yes, this is what I've also linked (one of the last comment in the issue), but as its documentation states it is just a temporal solution which is not too convincing and does not seems to be a stable solution:
This branch is just a work around to fix [a wasm bug](https://github.com/tomaka/wasm-timer/pull/13).

[hamza1311]

Does gloo-timers solve the problem for you?

[gzp79]

Does gloo-timers solve the problem for you?

hm, seems to be backed up by a working group for wasm but never heard of it before. Thank I will give it a try.

[hamza1311]

hm, seems to be backed up by a working group for wasm but never heard of it before

It's in the same organization as this repository, though I'm currently the only one maintaining it. If you encounter any issues, please file them at https://github.com/rustwasm/gloo

[Darksonn]

Please be aware that yield_now is completely runtime independent. The documentation mentions Tokio, but it should work in any runtime.

[hamza1311]

@Darksonn would you consider this (completely single threaded) (or this (uses atomics)) to be a "runtime" where yield_now works? If so, what should it actually be doing?

Note that spawn_local calls Task::spawn

[gzp79]

From my point of view I've managed to solve my issue with some refactor that don't require yield any more (and that is a much preferred solution). Thanks for the valuable comments on all forums/threads, now I have a bit better understanding of the system.

If you feel as the wasm bindgen runtime can be improved anyway w.r.t the original question, than please keep this ticket open, but from my side I'd suggest closing it.

[Darksonn]

@hamza1311 Whether yield_now results in starvation normally depends on the loop that calls run rather than the run method itself. Your run method looks fine to me.