UDPSession no longer flushes output queue on Close
cohosh opened this issue · 3 comments
Ever since 651dc4a, a UDPSession
will not flush queued outgoing packets when the connection is closed. Instead, there is a race condition in the select
call of postProcess
when the s.die
channel is closed in Close
:
select {
case buf := <-s.chPostProcessing: // dequeue from post processing
[snip]
// notify chCork only when chPostProcessing is empty
if len(s.chPostProcessing) == 0 {
select {
case chCork <- struct{}{}:
default:
}
}
case <-chCork: // emulate a corked socket
if len(txqueue) > 0 {
s.tx(txqueue)
// recycle
for k := range txqueue {
xmitBuf.Put(txqueue[k].Buffers[0])
txqueue[k].Buffers = nil
}
txqueue = txqueue[:0]
}
case <-s.die:
return
}
if Close
is called immediately after a Write
, the queued packets will not be sent. This wasn't an issue before because the uncork
function was called from within Close
.
I noticed this because one of our unit tests started failing when we tried to update the version of this library.
master...hotfix273
HI @cohosh, can you try this commit?
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 sess.chPostProcessing
.
I just tried this locally but even with this fix there's still another problem where by the time the output callback sends to sess.chPostProcessing
, the select
statement in postProcess
has already died because at the time, there wasn't anything in that channel.
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
sess.chPostProcessing
.
No,we can't do that, if chPostProcessing is full(because postProcess exits). It blocks forever on waiting for sending.
I just tried this locally but even with this fix there's still another problem where by the time the output callback sends to
sess.chPostProcessing
, theselect
statement inpostProcess
has already died because at the time, there wasn't anything in that channel.
Yup, The thing is a session cannot wait forever. So If 'Close()' is called, the session makes the 'best-effort delivery'.