stop generating new packets when the send queue is full #2971
Conversation
session.go
Outdated
| // nothing to see here. | ||
| // We do all the interesting stuff after the switch statement, so | ||
| // nothing to see here. | ||
| case <-sendQueueAvailable: |
There was a problem hiding this comment.
Do we need to drain sendQueueAvailable if we end up taking another path in this switch, and then enter the if checks below? Otherwise it could be that we incorrectly assume there's space available even if there isn't, right?
There was a problem hiding this comment.
The select can unblock for multiple reasons (sending scheduled, receiving a packet, etc.), so we always have to check if there's room in the send queue before sending a packet: https://github.com/lucas-clemente/quic-go/blob/b4ffb97831546fc8336ed5f0c37ed6b6c8c40246/session.go#L621-L629
There was a problem hiding this comment.
I think I misunderstood your comment. Draining the channel makes sense if WouldBlock() returns true.
There was a problem hiding this comment.
Actually, that would be racy (the send queue could have unblocked between the calls to WouldBlock and Available.
| type sendQueue struct { | ||
| queue chan *packetBuffer | ||
| closeCalled chan struct{} // runStopped when Close() is called | ||
| runStopped chan struct{} // runStopped when the run loop returns | ||
| available chan struct{} |
There was a problem hiding this comment.
This is a bit difficult to follow, and tightly coupled to run loop internals (e.g. if you use it wrong it's inherently racy, see below).
I wonder whether there's a simpler way of achieving similar behavior? Not sure if it's simpler, but possibly a nextPacket member in the session that we try to send in the session's switch statement?
(If we decide to stick with this, we should probably document the reasoning behind this API.)
There was a problem hiding this comment.
I'm not sure I understand why it's inherently race. It's true that the sendQueue can only be used from a single Go routine (which we guarantee by just running it from the session), but as long as you adhere to this, there shouldn't be any race here.
marten-seemann
force-pushed
the
send-queue-non-blocking
branch
2 times, most recently
from
de0da41
to
3b37e44
Compare
Codecov Report
@@ Coverage Diff @@
## master #2971 +/- ##
==========================================
+ Coverage 86.06% 86.08% +0.02%
==========================================
Files 135 135
Lines 9415 9435 +20
==========================================
+ Hits 8103 8122 +19
- Misses 953 954 +1
Partials 359 359
Continue to review full report at Codecov.
|
marten-seemann
force-pushed
the
send-queue-non-blocking
branch
2 times, most recently
from
a90c6e5
to
dd13de1
Compare
marten-seemann
force-pushed
the
send-queue-non-blocking
branch
from
dd13de1
to
72f2092
Compare
marten-seemann
force-pushed
the
send-queue-non-blocking
branch
from
72f2092
to
b81a6f8
Compare
Fixes #2941. Depends on #2980.
We shouldn't block the
runloop in the session ifWriteTois too slow to send out packets. If we do that, we won't be able to receive any incoming packets, and thereceivedPacketschannel might overflow, leading to avoidable packet loss.