How does current_thread runtime work?

[LIParadise]

So I came across this discussion and got confused: so the I/O and timer drivers of current_thread flavor runtime lives on the first thread m since m called runtime::Runtime::block_on right in the beginning thanks to #[tokio::main] macro expansion, so they are blocked altogether by std::thread::JoinHandle::join, effectively stopping the whole executor since the timer driver never has a chance notifying the runtime on m.

What I don't understand is why then this slightly modified snippet doesn't suffer similar issue?

At first, I assumed the program is doing something like this: the runtime lives on thread m so all the futures are driven by thread m; at t0, m called thread::spawn, at t1, thread::spawn finished and m then calls thread::JoinHandle::wait and is then blocked, which should also stops the current_thread executor from doing any other work, after which around 10 ms later at t2 the thread s tries to append a task to the runtime, which again lives on thread m.

So t2 is later than t1, i.e. new task is appended to the runtime task queue (which again lives on m) after m got blocked.

How does the task even got poll-ed?

I tried to explain the behavior by adding the thread::ThreadId prints, and came up with this explanation: a handle of a current_thread runtime, when member function runtime::Handle::block_on called from other threads, actually initializes a new executor (task queue) on that thread, albeit most likely without the I/O or timer drivers, since those lives on the first thread which calls runtime::Runtime::block_on (in this case m again thx to #[tokio::main]); in this case, the task is actually poll-ed by thread s, so the fact that m is blocked doesn't affect its execution; it's only when thread s tries to access tokio I/O or timer facilities problem would occur, since m is still owning the I/O and timer drivers.

Is tokio doing something akin to such an explanation? I mean runtime::Handle::block_on did state that This runs the given future on the current thread, but I'm still a bit uncertain about if it's really what tokio intends to do.
Or I've missed some important characteristics of tokio?

use tokio::*;

#[tokio::main(flavor = "current_thread")]
async fn main() {
    // let's call this thread `m` for `main`
    println!("Thread `m` has ID thread {:?}", std::thread::current().id());
    call_sync();
    println!("main thread finished!");
}

pub fn call_sync() {
    let handle = runtime::Handle::current();
    // let's call this spawned thread `s`
    let thread_s_result = std::thread::spawn(move || {
        std::thread::sleep(std::time::Duration::from_millis(10));
        handle.block_on(async_print())
    })
    .join();
    println!("{thread_s_result:?}");
}

pub async fn async_print() {
    async {
        println!(
            "I'm in async block, thread {:?}",
            std::thread::current().id()
        );
    }
    .await
}

[mox692]

What I don't understand is why then this slightly modified snippet doesn't suffer similar issue?

Since this time your program uses std::thread::sleep which doesn't require a runtime driver invocation, your main thread can receive a notification and proceed.

[LIParadise]

Thx for the reply, but isn't the main thread blocked by thread::join? How could the executor drive any other future if it's single-threaded on the main thread which is currently blocked?

Maybe I should instead ask this: does runtime::Handle::block_on when called from threads other than the one on which the runtime lives, it actually creates a new local task queue on that thread? And if that's the case, does the usual multi-thread runtime work stealing logic apply?

[Darksonn]

When you use Handle::block_on, then that will execute the future you pass it, but the thread is not otherwise part of the runtime. No other futures are executed there. This applies to both current-thread and multi-thread.

Note that Runtime::block_on is slightly different. There, with the current-thread runtime, one of the block_on calls becomes where the real runtime is running. Any extra calls are just like Handle::block_on in that they execute the future they're given and nothing else.

[LIParadise]

Ok, I think I understand now:

Both in this snippet and in the first program in the original linked discussion it's the std::thread::spawn-ed thread that's executing the new future; the main thread is temporarily blocked in both cases.
The difference is that in the linked example the new future is waiting for timer driver which is on a blocked thread, causing dead lock, whereas here in this example std::thread::sleep completes just fine and the main thread is later unblocked since thread::JoinHandle::join completed.

Does such an interpretation make any sense?

[Darksonn]

Yes, tokio::time::sleep can only make progress when the actual runtime thread is not blocked, because the thread containing the actual runtime is where Tokio keeps track of all of the timers and IO resources.

[LIParadise]

Understood. Thx a lot!