Skip to content

Conversation

@JonathanHenson
Copy link
Contributor

…where the request kicks off before the stream container itself has had a chance to be seated by the user.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

…where the request kicks off before the stream container itself has had a chance to be seated by the user.
@JonathanHenson JonathanHenson requested a review from a team March 14, 2020 00:34
Copy link
Contributor

@justinboswell justinboswell left a comment

Choose a reason for hiding this comment

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

Good to go other than the one issue

Copy link
Contributor

@graebm graebm left a comment

Choose a reason for hiding this comment

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

I'm disturbed by how quick this was

Comment on lines 477 to 483
{ /* BEGIN CRITICAL SECTION */
s_h1_connection_lock_synced_data(connection);

if (connection->synced_data.new_stream_error_code) {
new_stream_error_code = connection->synced_data.new_stream_error_code;
} else {
aws_linked_list_push_back(&connection->synced_data.new_client_stream_list, &stream->node);
if (!connection->synced_data.is_outgoing_stream_task_active) {
connection->synced_data.is_outgoing_stream_task_active = true;
should_schedule_task = true;
}
}

s_h1_connection_unlock_synced_data(connection);
} /* END CRITICAL SECTION */
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we should move this whole critical section into activate()?
That way we only grab the lock once
I could see an argument that you'd rather see a "no new streams allowed" exception sooner than later
I'm really not sure on this one, just bringing it up.

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'm not sure on this one either, but I suspect a fast fail if there's a connection error (such as a connection: close header received), we want this to fail sooner rather than later.

Copy link
Contributor

@graebm graebm left a comment

Choose a reason for hiding this comment

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

Nice, we still need to add a test that creates a stream but never activates it, to be 100% sure this all cleans up right

…quest level option altogether. Added tests to verify unactivated streams still properly clean-up.
@JonathanHenson JonathanHenson merged commit f5096ca into master Mar 27, 2020
@JonathanHenson JonathanHenson deleted the stream_activation branch March 27, 2020 02:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants