Skip to content

fix(registry): make sure to process a download after it has completed#14680

Closed
x-hgg-x wants to merge 1 commit intorust-lang:masterfrom
x-hgg-x:fix-source-fetch
Closed

fix(registry): make sure to process a download after it has completed#14680
x-hgg-x wants to merge 1 commit intorust-lang:masterfrom
x-hgg-x:fix-source-fetch

Conversation

@x-hgg-x
Copy link
Contributor

@x-hgg-x x-hgg-x commented Oct 12, 2024

What does this PR try to resolve?

This PR solves the bug found in Eh2406/pubgrub-crates-benchmark#6 (comment).

With this PR we can avoid refetching the same dependency multiple times because a finished download was not processed before returning from the block_until_ready() method. It also improves the resolving speed since activate_deps_loop() is called less times overall.

@rustbot
Copy link
Collaborator

rustbot commented Oct 12, 2024

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added A-registries Area: registries A-sparse-registry Area: http sparse registries S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 12, 2024
@Eh2406
Copy link
Contributor

Eh2406 commented Oct 14, 2024

I've never had a deep grasp of the semantics of the curl crate. So I'm not going to take lead on reviewing this PR.

@arlosi
Copy link
Contributor

arlosi commented Oct 15, 2024

@x-hgg-x thanks for reporting and creating this fix!

I did some additional investigation and added additional testing in this area in a new PR #14694.

@x-hgg-x
Copy link
Contributor Author

x-hgg-x commented Oct 15, 2024

Closed in favor of #14694.

@x-hgg-x x-hgg-x closed this Oct 15, 2024
@x-hgg-x x-hgg-x deleted the fix-source-fetch branch October 15, 2024 19:15
bors added a commit that referenced this pull request Oct 15, 2024
fix(registry): `HttpRegistry` `block_until_ready` returns early when work is still pending

### What does this PR try to resolve?

`block_until_ready` is returning early when there are still pending transfers. This leads to extra restarts of the resolver, impacting performance.

In the existing implementation:
- `handle_completed_downloads` runs and there are no completed downloads
- `multi.perform()` is called and completes new downloads, with no pending transfers remaining
- Since there are no items `remaining_in_multi`, the function returns early

This fixes the issue by reordering the calls to `multi.perform()`, `handle_completed_downloads`, then the completion check.

### How should we test and review this PR?

A test is added that uses cargo's tracing to show the number of blocking calls. First commit shows existing behavior, second commit shows fix.

Originally based on the PR #14680 by `@x-hgg-x.` The ordering fix in this PR also avoids an additional `block_until_ready` call for retried failed downloads.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-registries Area: registries A-sparse-registry Area: http sparse registries S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants