Skip to content

Conversation

FranciscoTGouveia
Copy link
Contributor

Related to the introduction of the RUSTUP_CONCURRENT_DOWNLOADS environment variable in #4450.

This fixes the erroneous behavior of making the progress bar start ticking for all downloads at once, even when we are not in a situation of max concurrency.

PS: This situation can be observed in this animation (the first one).

…tead of cumulative

Before this commit, if RUSTUP_CONCURRENT_DOWNLOADS < 6, the timer for
the components download would start at the same time for every one of
them instead of just starting when the actual download begins.
@@ -81,6 +81,7 @@ impl DownloadTracker {
/// Sets the length for a new ProgressBar and gives it a style.
pub(crate) fn content_length_received(&mut self, content_len: u64, url: &str) {
if let Some(pb) = self.file_progress_bars.get(url) {
pb.reset();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it still useful that we're building the ProgressBar for DownloadingComponent, rather than starting at DownloadContentLengthReceived?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is justifiable since we don’t have access to the component’s name when creating a DownloadContentLengthReceived notification -- only the URL.

With that in mind, and wishing to avoid parsing the URL to extract the component’s name, I think it’s best to keep the creation of the ProgressBar within the DownloadingComponent notification.

Additionally, I’d like to note that when retrying a download, the DownloadingComponent notification is not sent again. Moving the creation of the ProgressBar to the DownloadContentLengthReceived notification could complicate the logic in the DownloadTracker, particularly when handling download retries.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moreover, I’d like to add that creating the ProgressBar within DownloadingComponent is the only way to ensure the output remains in the correct order when handling concurrent downloads.

@djc
Copy link
Contributor

djc commented Aug 29, 2025

I think this looks okay. It seems a little unintuitive to me to wait until the DownloadContentLengthReceived since it would ignore any latency from waiting for the header response, but I guess in practice that's probably a trivial part of the download time anyway.

Copy link
Member

@rami3l rami3l left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the justification is clear enough, so I agree to merge it first and see how it goes :)

@rami3l rami3l added this pull request to the merge queue Aug 29, 2025
Merged via the queue into rust-lang:master with commit 63b4e21 Aug 29, 2025
29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants