-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Registry functions return Poll to enable parallel fetching of index data #10064
Merged
Merged
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I think one of the fundamental questions is can
block_until_ready
spuriously wake?I.E. If
block_until_ready
returns, can the next call toquery
returnPoll::Pending
?If Yes, then this loop is correct. But we should document it.
If No, then this loop seems like overkill. As it has to pass on the second iteration. (The same pattern is also true in other loops but I'm only gonna comment here.)
Another fundamental question is what happens if you call
block_until_ready
on a source that has not yet returnedPoll::Pending
?To be specific, do we iterate over
sources.iter_mut()
or only the ones that are still inpackage_ids
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For a given source and query parameters, a
query
call that previously returnedPoll::Pending
must returnPoll::Ready
after callingblock_until_ready
. If the query parameters are different (such as querying for a package that hasn't been queried before), thenquery
may returnPoll::Pending
, even after ablock_until_ready
call.Calling
block_until_ready
if a source hasn't yet returned aPoll::Pending
is an interesting question. If you callinvalidate_cache
+block_until_ready
, the git-based sources will do a fetch.I agree we should be more precise here and only call
block_until_ready
for the sources remaining inpackage_ids
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we trust that must then we don't need a loop. So instead of "loops" like:
We can have:
of course will probably want some kind of helper to DRY the redundant
self.config()?
. And possibly a helper to deal with (the two) places where we have a vec of things to query.Overnight the possibility of weakening it to should started to grow on me. So someone implementing the trait should make sure that the second query always returns a Ready. But, someone using the trait has to loop calling
block_until_ready
until the query returns Ready.Whatever we decide we should document it on the trait.
I think we should define
block_until_ready
beforePoll::Pending
/invalidate_cache
as a NOP. For example this loop callsblock_until_ready
on allsources
even if only some of them need it:cargo/src/cargo/core/registry.rs
Lines 730 to 734 in f12f025
Keeping track of witch ones need it, seams like a lot of extra work.
Can we document on the trait when it is an NOP, and point out that it is a recommended optimization to avoid unneeded calls to
block_until_ready
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I've changed it to should return
Poll::Ready
afterblock_until_ready
and updated the doc comments. Let me know if it makes more sense now!