Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Avoid spurious wakeups when stream capacity is not available #661

Merged
merged 2 commits into from Feb 20, 2023
Merged

Avoid spurious wakeups when stream capacity is not available #661

merged 2 commits into from Feb 20, 2023

Commits on Feb 17, 2023

  1. test erroneous poll_capacity makeup on window update

    @vadim-eg
    vadim-eg committed Feb 17, 2023
    Configuration menu
    Copy the full SHA
    865ca86 View commit details
    Browse the repository at this point in the history

  2. Avoid spurious wakeups when stream capacity is not available 

    Fixes hyperium#628

Sometimes `poll_capacity` returns `Ready(Some(0))` - in which case
caller will have no way to wait for the stream capacity to become available.
The previous attempt on the fix has addressed only a part of the problem.

The root cause - in a nutshell - is the race condition between the
application tasks that performs stream I/O and the task that serves
the underlying HTTP/2 connection. The application thread that is about
to send data calls `reserve_capacity/poll_capacity`, is provided
with some send capacity and proceeds to `send_data`.

Meanwhile the service thread may send some buffered data and/or
receive some window updates - either way the stream's effective
allocated send capacity may not change, but, since the capacity still
available, `send_capacity_inc` flag may be set.

The sending task calls `send_data` and uses the entire allocated
capacity, leaving the flag set. Next time `poll_capacity` returns
`Ready(Some(0))`.

This change sets the flag and dispatches the wakeup event only in
cases when the effective capacity reported by `poll_capacity` actually
increases.
    @vadim-eg
    vadim-eg committed Feb 17, 2023
    Configuration menu
    Copy the full SHA
    1f6464e View commit details
    Browse the repository at this point in the history