Switch from sync to a tokio runtime

[rbtcollins]

Being able to use async where relevant across the codebase makes it possible to use async constructs where relevant. rustup has many places where that can be useful: downloading channel metadata, distribution content, unpacking that content to disk, are work that could usefully proceed in parallel - and async provides a good abstraction for that.

We already have a sophisticated disk IO layer that accomodates various OS latency-inducing behaviours, and adapting that to async without any regressions could be very interesting too - but for now, it co-exists nicely with an async core.

One not necessarily obvious caveat - we can't use tokio::main because it doesn't provide the per-worker-thread injection that we use to facilitate isolated tests. (tl;dr std::env::var/args being global reflect reality well, but not writing tests that interact with those layers).

[djc]

Having briefly skimmed over some parts of this: what limits us from just using #[tokio::main] and making things natively async, rather than all the callback stuff and block_on() type calls?

[rbtcollins]

Having briefly skimmed over some parts of this: what limits us from just using #[tokio::main] and making things natively async, rather than all the callback stuff and block_on() type calls?

This is in draft mode at the moment because it is incomplete.

The block-on stuff is scaffolding during the transition.

The starting point was:
sync main()
...
reqwest blocking http client
tokio runtime invoked here

With an async main, that will blow up at runtime, because you get
tokio runtime
async main()
...
reqwest blocking http client
tokio runtime invoked here - panic

If that is changed naively by just making main() async, and reqwest async, then we get rust's async function tainting everything and will change all the relevant calls to async, but there are a number of places where types need to change to be compatible with async requirements; so the commit becomes huge and unwieldy very quickly.

So the approach I'm taking is some scaffolding that lets us work this incrementally, and once complete it will just be nice async code.

[djc]

Makes sense, thanks for the explanation. Can you give an example of where/how types need to change? I worry that with this approach, you'll need another big set of commits to unwind all the block_on() stuff again after switching main. Instead, maybe it would be possible to use the top-down approach to isolate the required type changes in their own commits, and then jump directly to full async mode from there by adding async keywords all over the place?

[rbtcollins]

Once done the aggregate diff should be precisely the changes needed, and I can rebase squash it all away. We did this with the removal of failure. Many many small steps, nice outcome :)

[djc]

Oh, I guess that makes sense. Other projects I help maintain prefer to rebase-merge so that the small commits make it into main, which can be helpful if you need to chase down a regression later.

[rbtcollins]

Thats also valid to do; lets assess when this is at the next inflection point (which will be async native with no thunk, but no refactorings for better behaviour)

[rbtcollins]

This is nearly complete, I think its mostly mechanical now, except for the closures in the test suite - there's some lifetime challenges to address there

[rbtcollins]

This now complete modulo any refactoring of the commit series we might want to do.

The key notes are:

• we can't use tokio::main because it doesn't provide the per-worker-thread injection that we use to facilitate isolated tests. (tl;dr std::env::var/args being global reflect reality well, but not writing tests that interact with those layers).

[djc]

This looks mostly okay to me.

[rami3l]

Thanks a lot for your hard work, @rbtcollins and @djc!