Conversation
mmerickel
force-pushed
the
outbuf-high-watermark
branch
from
0329dab to
b9dbed8
Compare
mmerickel
force-pushed
the
outbuf-high-watermark
branch
2 times, most recently
from
ba55660 to
908573f
Compare
mmerickel
force-pushed
the
outbuf-high-watermark
branch
2 times, most recently
from
5722d8e to
6534d80
Compare
mmerickel
force-pushed
the
outbuf-high-watermark
branch
from
6534d80 to
7268909
Compare
mmerickel
force-pushed
the
outbuf-high-watermark
branch
from
7268909 to
b4df005
Compare
Co-Authored-By: mmerickel <github@m.merickel.org>
mmerickel
force-pushed
the
outbuf-high-watermark
branch
from
b9d0a3e to
291f8e1
Compare
digitalresistor
left a comment
digitalresistor
left a comment
There was a problem hiding this comment.
Looks great, minor nitpicks.
| # that we need to account for, otherwise it'd be better | ||
| # to do this check at the start of the request instead of | ||
| # at the end to account for consecutive service() calls | ||
| if len(self.requests) > 1: |
There was a problem hiding this comment.
Would it make sense here to kick the trigger?
There was a problem hiding this comment.
I'm not familiar with the scenarios in which kicking the trigger is required.
There was a problem hiding this comment.
It's not like the current behavior is worse than it was before. I would assume the situation is that the write returned 0 bytes written because the buffer was full, and the system would know that more data is writable before hitting a select timeout or something. If you think it's a problem then it should be kicked in _flush_outbufs_below_high_watermark which affects both app_iter writes as well as here between requests. I can't imagine the circumstances are different here than there.
2 participants
Fixes #67.
The
outbuf_high_watermarkis a setting that can be used to apply backpressure on theapp_iterif it is yielding data faster than can be written to the client. When the socket falls behind, theapp_iterwill not resume until the socket catches up to at least the watermark (this does not mean the socket is caught up, just that it's not so far behind).