-
Notifications
You must be signed in to change notification settings - Fork 11
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
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
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>
In this revision, I've replaced the One test was previously failing due to the poll_index not incrementing properly |
return None; | ||
}; | ||
|
||
self.waker.take().map(|waker| waker.wake()); |
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.
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; |
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.
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.)
This PR refactors the substream-set (used by request-response protocols):