-
Notifications
You must be signed in to change notification settings - Fork 726
unbuffered: do not prematurely consume data #2338
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
Conversation
Benchmark resultsInstruction countsSignificant differencesThere are no significant instruction count differences Other differencesClick to expand
Wall-timeSignificant differencesThere are no significant wall-time differences Other differencesClick to expand
Additional informationCheckout details:
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2338 +/- ##
==========================================
- Coverage 94.89% 94.89% -0.01%
==========================================
Files 103 103
Lines 24274 24292 +18
==========================================
+ Hits 23034 23051 +17
- Misses 1240 1241 +1 ☔ View full report in Codecov by Sentry. |
68062c6
to
ece443f
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.
Not a very in-depth review, I don't have all the unbuffered API context swapped in anymore.
} else { | ||
self.taken = true; | ||
Some(Ok(AppDataRecord { | ||
self.chunk = self |
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.
On ReadTraffic
Drop
, should we put back the chunk
if Some
?
(I guess this is covered by your commit message saying that next_record()
remains one-shot.)
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.
No. This is the point at which the chunk is consumed. We need to save it in self.chunk
to get a place for AppDataRecord
to borrow from.
Previously, the point at the application is given a `ReadTraffic` state is when the data is consumed. That meant `ReadTraffic::peek_len()` was too late for an application to decide not to accept the data just yet. Note that `ReadTraffic::next_record()` remains one-shot, as there is at most one item in `received_plaintext` in unbuffered mode.
ece443f
to
7da79ad
Compare
This alters
ReadTraffic
andReadEarlyData
so that theirnext_record()
functions are where the data is consumed, allowingpeek_len()
functions work as intended.fixes #2031