Timer documentation says confusing things about the task queue about glommio HOT 4 CLOSED

UPDATE: Never mind. The reason I was seeing blocking is because I had a background task spinning on a future that always returned an error so it never yielded. So not relevant to the above & still confused by the note.

Ok, I am seeing scenarios where the Timer never returns if I await a tokio oneshot receiver and attach an .or with a timer to that future:

   let (_tx, rx) = tokio::oneshot::channel();
   rx.or(async move {
      glommio::sleep(Duration::from_millis(30));
   }).await // Deadlock!!!

The timeout code does work if I use glommio::timeout so I suspect this deadlock is what the Timer docs refer to. What's confusing is that on the front page of the docs the example has:

    let timeout = async {
        Timer::new(Duration::from_secs(10)).await;
        Err(io::Error::new(io::ErrorKind::TimedOut, "").into())
    };
    let stream = TcpStream::connect("::80").or(timeout).await?;

which would then seem like an erroneous example to have without the warning / an explanation of why this example might work but others following the same pattern won't in other cases (or maybe the example itself doesn't work which would be even worse).

from glommio.

@glommer if you get a chance I'd love to understand what the warning means if you remember.

from glommio.

The wording there is not the best, since it doesn't really block it.
What it means is that given Rust's concurrency model, calling .await will - as you put it - delay the current task.

I think I still had the seastar model in my mind when I wrote that code, in which a future starts executing immediately when you call it, and in my mind this behavior was "blocking"-like (but hey, it's been a while)

from glommio.

Ok. I'll put up a PR to clear up the wording.

from glommio.