There's nothing special going on. Remember, async on a function is something like
async fn function(argument: &str) -> usize {
fn function(argument: &str) -> impl Future<Item=usize> {
> If not, how does it deal with (possibly indirect) recursive function calls?
Recursive calls to async functions will fail to compile: https://github.com/rust-lang/rust/issues/53690
That said, see that discussion; the trait object form will probably eventually work.
Heavy recursion isn't generally Rust's style, since we don't have guaranteed TCO, so you threaten to overflow the stack and panic.
> Is refactoring into smaller async functions less efficient?
That's a complicated question. It really depends. I don't think it should be, thanks to inlining, but am not 100% sure.
> And what is the purpose of the pingpong between executor->Waker->push onto executor?
Right now, the best resource is https://boats.gitlab.io/blog/post/wakers-i/ and https://boats.gitlab.io/blog/post/wakers-ii/
> I am also still unsure what the approach to multithreading might be.
You have options! Tokio now does multiple executors with work-stealing by default, in my understanding.
From the second blog post I actually found https://github.com/tokio-rs/tokio/pull/660 which switched tokio from 1 reactor+worker threads to n reactors with work stealing.
There's nothing special going on. Remember, async on a function is something like
to so, when you call an async function, you get a Future back. That's true even if it's inside of another async function.> If not, how does it deal with (possibly indirect) recursive function calls?
Recursive calls to async functions will fail to compile: https://github.com/rust-lang/rust/issues/53690
That said, see that discussion; the trait object form will probably eventually work.
Heavy recursion isn't generally Rust's style, since we don't have guaranteed TCO, so you threaten to overflow the stack and panic.
> Is refactoring into smaller async functions less efficient?
That's a complicated question. It really depends. I don't think it should be, thanks to inlining, but am not 100% sure.
> And what is the purpose of the pingpong between executor->Waker->push onto executor?
Right now, the best resource is https://boats.gitlab.io/blog/post/wakers-i/ and https://boats.gitlab.io/blog/post/wakers-ii/
> I am also still unsure what the approach to multithreading might be.
You have options! Tokio now does multiple executors with work-stealing by default, in my understanding.