filesystem: send 'ready' on fsread1 and fslist1 #19196
Merged
Conversation
This file contains 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
It's not really conceptually clear that we should send 'ready' on channels that don't expect to receive data, so we haven't done it until now. Unfortunately, `Channel.ready()` is also the place we thaw the receive side of the channel, so those channels were never being thawed. The only place this matters for is flow control: pong messages will be received and queued, but never delivered, causing the channel to stall out after the window is filled for the first time. Let's send 'ready' everywhere. That fixes the flow control issue. It's what the C bridge does as well. Adjust our generic channel test case to make sure we always get the 'ready' message. Also move our uses of the low-level `.send_open()` for the `fsread1` and `fslist1` channels to use `.check_open()` (which waits for the ready message). Since we now see 'ready' in cases where the bridge isn't expecting data, remove a couple of assertions stipulating that the channel was definitely open to receive that data — it's possible we're getting a ready message from a channel that already sent all of its data and closed. Fixes cockpit-project#19192
mvollmer
approved these changes
Aug 14, 2023
We indeed lacked a unit test there. That got added in this PR. |
allisonkarlitskaya
merged commit 8a5bfc6
into
cockpit-project:main
34 of 35 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
It's not really conceptually clear that we should send 'ready' on channels that don't expect to receive data, so we haven't done it until now.
Unfortunately,
Channel.ready()is also the place we thaw the receive side of the channel, so those channels were never being thawed. The only place this matters for is flow control: pong messages will be received and queued, but never delivered, causing the channel to stall out after the window is filled for the first time.Let's send 'ready' everywhere. That fixes the flow control issue. It's what the C bridge does as well.
Adjust our generic channel test case to make sure we always get the 'ready' message. Also move our uses of the low-level
.send_open()for thefsread1andfslist1channels to use.check_open()(which waits for the ready message).Since we now see 'ready' in cases where the bridge isn't expecting data, remove a couple of assertions stipulating that the channel was definitely open to receive that data — it's possible we're getting a ready message from a channel that already sent all of its data and closed.
Fixes #19192