Description
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.
#3367
We are still using an async-unaware threadpool here, and it's known to produce problems (#3125):
Lines 1 to 6 in fa4ae32
Anyway, using RUSTUP_IO_THREADS=1
to limit concurrency feels a bit off. Will migrating to async
help?