-
-
Notifications
You must be signed in to change notification settings - Fork 423
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
Refactor receive stream buffering #758
Conversation
Codecov Report
@@ Coverage Diff @@
## master #758 +/- ##
==========================================
+ Coverage 71.33% 71.55% +0.21%
==========================================
Files 73 74 +1
Lines 13111 13277 +166
==========================================
+ Hits 9353 9500 +147
- Misses 3758 3777 +19
Continue to review full report at Codecov.
|
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.
Some early comments. Still chewing on the Assembler
state splitting...
(Also very well-factored commits here. In terms of preventing unnecessary rebase efforts, maybe submit the first four commits separately so we can merge them immediately?) |
Cherry-picked the simple stuff into #770. |
d993bd9
to
cde86cb
Compare
Rebased. |
2389fbf
to
f4d5058
Compare
Got rid of a bunch of unnecessary complexity regarding |
421a94e
to
a08e058
Compare
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.
Whew, I made it through. This is looking good (and definitely better than earlier). I think all of my comments are pretty cosmetic.
When there's a leading gap in the buffered data or unordered reads are in use, `self.offset` does not represent the starting point of the first chunk.
DataRecvd was used to identify when all data has been received but not yet read by the application, but we can determine that on-demand in the Recvd state.
Ensures we don't yield the same data to the application repeatedly, and only issue flow control credit in response to new data.
This was probably unreachable as we dispose of closed receive streams immediately after they become such, but if that ever changes we still don't want to panic.
Nice work. |
Fixes #735. Should marginally improve performance for ordered reads due to isolation of the (now somewhat more) complex
RangeSet
operations to the unordered case where they're necessary, leaving simple cursor-based logic for ordered behavior.