Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Be more lenient with streams in the pending_send queue. #261

Merged
merged 3 commits into from
May 10, 2018
Merged

Be more lenient with streams in the pending_send queue. #261

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f93fde9
Be more lenient with streams in the `pending_send` queue.
goffrie Apr 20, 2018
b7309eb
Add a debug_assert that the stream must be in a closed state.
goffrie Apr 27, 2018
474acaa
Merge branch 'master' into reset
carllerche May 9, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 14 additions & 15 deletions src/proto/streams/prioritize.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -578,14 +578,6 @@ impl Prioritize {
trace!("pop_frame; stream={:?}; stream.state={:?}",
stream.id, stream.state);

// If the stream receives a RESET from the peer, it may have
// had data buffered to be sent, but all the frames are cleared
// in clear_queue(). Instead of doing O(N) traversal through queue
// to remove, lets just ignore peer_reset streams here.
if stream.state.is_peer_reset() {
continue;
}

// It's possible that this stream, besides having data to send,
// is also queued to send a reset, and thus is already in the queue
// to wait for "some time" after a reset.
Expand Down Expand Up @@ -694,13 +686,20 @@ impl Prioritize {
)
),
None => {
let reason = stream.state.get_scheduled_reset()
.expect("must be scheduled to reset");

stream.state.set_reset(reason);

let frame = frame::Reset::new(stream.id, reason);
Frame::Reset(frame)
if let Some(reason) = stream.state.get_scheduled_reset() {
stream.state.set_reset(reason);

let frame = frame::Reset::new(stream.id, reason);
Frame::Reset(frame)
} else {
// If the stream receives a RESET from the peer, it may have
// had data buffered to be sent, but all the frames are cleared
// in clear_queue(). Instead of doing O(N) traversal through queue
// to remove, lets just ignore the stream here.
trace!("removing dangling stream from pending_send");
counts.transition_after(stream, is_counted, is_pending_reset);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you explain why this needs to be called here? I don't think this was called before (and I could believe it was another bug).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that it was not called before. I think that it should be, otherwise we could leak streams - it's possible that the pending_send queue here was holding onto the last reference to the stream.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is highly likely that this change is correct, but i'd like to see if we can figure out a failing test case.

continue;
}
}
};

Expand Down
7 changes: 0 additions & 7 deletions src/proto/streams/state.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -325,13 +325,6 @@ impl State {
}
}

pub fn is_peer_reset(&self) -> bool {
match self.inner {
Closed(Cause::Proto(_)) => true,
_ => false,
}
}

/// Returns true if the stream is already reset.
pub fn is_reset(&self) -> bool {
match self.inner {
Expand Down