-
Notifications
You must be signed in to change notification settings - Fork 739
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
UDPSession no longer flushes output queue on Close #273
Comments
master...hotfix273 |
Thanks, that got rid of some of the race conditions but it looks like there are some remaining and our tests are still failing. There's one in the output callback: // delivery to post processing
select {
case sess.chPostProcessing <- bts:
case <-sess.die:
return
} We could probably just remove the select statement here and always send the bytes to I just tried this locally but even with this fix there's still another problem where by the time the output callback sends to |
No,we can't do that, if chPostProcessing is full(because postProcess exits). It blocks forever on waiting for sending.
Yup, The thing is a session cannot wait forever. So If 'Close()' is called, the session makes the 'best-effort delivery'. |
An update the the kcp-go library removes the guarantee that all data written to a KCP connection will be flushed before the connection is closed. Moving the sleep call has no impact on the integrity of the tests, and gives the connection time to flush data before the connection is closed. See xtaci/kcp-go#273
Ever since 651dc4a, a
UDPSession
will not flush queued outgoing packets when the connection is closed. Instead, there is a race condition in theselect
call ofpostProcess
when thes.die
channel is closed inClose
:if
Close
is called immediately after aWrite
, the queued packets will not be sent. This wasn't an issue before because theuncork
function was called from withinClose
.I noticed this because one of our unit tests started failing when we tried to update the version of this library.
The text was updated successfully, but these errors were encountered: