-
Notifications
You must be signed in to change notification settings - Fork 284
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
Assertion failure for concurrent read and close calls on a single TCPConnection #1376
Labels
Comments
s-ludwig
changed the title
is this a bug?
Assertion failure for concurrent read and close calls on a single TCPConnection
Jan 27, 2016
Was indeed a bug. Now properly throws an |
s-ludwig
added a commit
that referenced
this issue
Feb 26, 2016
…ion.close(). The previous fix for #1376 resulted in a possible task starvation when the peer reset the connection before the outbound buffer was drained. The new approach now always resumes the waiting task exactly once, no matter how many events happen and no matter in which order.
s-ludwig
added a commit
that referenced
this issue
Feb 27, 2016
…ion.close(). The previous fix for #1376 resulted in a possible task starvation when the peer reset the connection before the outbound buffer was drained. The new approach now always resumes the waiting task exactly once, no matter how many events happen and no matter in which order. (cherry picked from commit 350130a)
machindertech
pushed a commit
to machindertechnologies/vibe.d
that referenced
this issue
Feb 27, 2016
…ion.close(). The previous fix for vibe-d#1376 resulted in a possible task starvation when the peer reset the connection before the outbound buffer was drained. The new approach now always resumes the waiting task exactly once, no matter how many events happen and no matter in which order. (cherry picked from commit 350130a)
s-ludwig
added a commit
that referenced
this issue
Apr 10, 2016
…ion.close(). The previous fix for #1376 resulted in a possible task starvation when the peer reset the connection before the outbound buffer was drained. The new approach now always resumes the waiting task exactly once, no matter how many events happen and no matter in which order. (cherry picked from commit 350130a)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
when client socket send msg or disconnect, this demo will crash.
The text was updated successfully, but these errors were encountered: