This repository was archived by the owner on Nov 15, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Flush stream after we try to send data - always. #8405
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Since this is local, if a flush is needed but
poll_flushreturnsPoll::Pending, it looks like the handler may not callpoll_flush()again when it is next polled? I would think that not wanting to track such state is why the current code always callspoll_flush()for each open substream in the removed block above. Please correct me if I'm mistaken.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.
Good point!
The problem that we have encountered is that flush wasn't called at all, we assume that this was probably due to other substreams being more busy or whatever.
As I'm thinking more about this, the current implementation isn't really robust. It could happen that a stream with a lower
procotol_indexcould starve other streams. There is already thisevents_queue. We should insert every event in there and to ensure that we poll all incoming and outgoing streams. At the end of this loop we should check if there is something in theevents_queueand return that.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.
Good catch @romanb ! Thanks!
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.
Problem: We lose back pressure.
events_queuecould grow indefinitely in that case.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 do we loose the back pressure? The event queue was checked before we polled for new events?
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.
Yeah, I wanted to avoid checking before and after and if we only check afterwards, we got that issue. If we only checked first, we would return
Pendingalthough we are actuallyReady. Either way @tomaka seems skeptic that we solve anything here.