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.

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

Make sure stream.Read() unblocks for close + reset #66

Merged

Conversation

ncdc
Copy link
Contributor

@ncdc ncdc commented Mar 10, 2016

Make sure that stream.Read() always unblocks after a stream.Close() followed by a stream.Reset().
Even if the stream is considered finished (which happens when you call stream.Close()), we need to
still call stream.closeRemoteChannels() when stream.Reset() is called, regardless of the value of
stream.finished. This ensures that stream.closeChan is closed, which unblocks readers.

Make sure that stream.Read() always unblocks after a stream.Close() followed by a stream.Reset().
Even if the stream is considered finished (which happens when you call stream.Close()), we need to
still call stream.closeRemoteChannels() when stream.Reset() is called, regardless of the value of
stream.finished. This ensures that stream.closeChan is closed, which unblocks readers.
@ncdc
Copy link
Contributor Author

ncdc commented Mar 10, 2016

@dmcgowan yet another edge case, /sigh. PTAL and let me know what you think. Thanks!!!

@dmcgowan
Copy link
Member

Too bad more people aren't using this library so they can take advantage of all this hardening you are doing 😄

Curious if you guys are planning on switching to something HTTP2 based like gRPC? I need to play around with it more to see what I could recommend as alternatives while getting the same easy stream access.

LGTM

dmcgowan added a commit that referenced this pull request Mar 10, 2016
…-reset

Make sure stream.Read() unblocks for close + reset
@dmcgowan dmcgowan merged commit 449fdfc into moby:master Mar 10, 2016
@ncdc
Copy link
Contributor Author

ncdc commented Mar 10, 2016

We are hoping to switch to HTTP/2 once we move to go 1.6. I did a POC in Kubernetes that hacked it in for exec/attach/port-forward using a prerelease version of 1.6. It had some issues and was quite rough about the edges, but I'm optimistic I'll be able to make it work.

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.

2 participants