Skip to content

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

@lexnv lexnv added the enhancement New feature or request label Sep 3, 2024
@lexnv lexnv self-assigned this Sep 3, 2024
@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

@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

@lexnv lexnv requested a review from dmitry-markin September 23, 2024 15:34
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.)

@lexnv
Copy link
Collaborator Author

lexnv commented Feb 27, 2025

Planning to remove this entirely in the future, this is no longer needed

@lexnv lexnv closed this Feb 27, 2025
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