Skip to content
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

substream-set: Poll substreams fairly with poll indexes #228

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

lexnv
Copy link
Collaborator

@lexnv lexnv commented Sep 3, 2024

This PR refactors the substream-set (used by request-response protocols):

  • the context waker is saved to before returning poll::pending
  • a poll index and vec is introduced to provide more fairness during the polling of substreams

Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
@lexnv lexnv added the enhancement New feature or request label Sep 3, 2024
@lexnv lexnv self-assigned this Sep 3, 2024
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
@lexnv
Copy link
Collaborator Author

lexnv commented Sep 4, 2024

I'll do more testing with this PR since one test is failing because we expect fewer polls to happen

and use IndexMap

Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
@lexnv
Copy link
Collaborator Author

lexnv commented Sep 23, 2024

In this revision, I've replaced the HashMap ++ Vec<Keys> with an indexMap::IndexMap.

One test was previously failing due to the poll_index not incrementing properly

return None;
};

self.waker.take().map(|waker| waker.wake());
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think we need to wake the task when removing a substream. I.e., all the remaining futures in the map were already registered in the task context.


for _ in 0..len {
let index = inner.poll_index % len;
inner.poll_index = (inner.poll_index + 1) % len;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why not just toss the starting index randomly when poll_next is called? This way we won't need to keep the last starting index, and the polling will be even more random than when just offsetting by 1. I.e., when we offset the index by one there are still more chances to poll substreams from the first half of the list until the starting index offsets significantly.

Also, I would even keep a HashMap for additional shuffling instead of using IndexMap that keeps the insertion order. (We will need to traverse the HashMap twice to implement iteration starting from some offset. This should not be a problem, but double check the order of the HashMap iteration is the same if the map hasn't changed between the iterations, please.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants