Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: cloudflare/quiche
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: master
Choose a base ref
...
head repository: cloudflare/quiche
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: evanrittenhouse/handshake-cancellation
Choose a head ref
Checking mergeability… Don’t worry, you can still create the pull request.
  • 2 commits
  • 4 files changed
  • 1 contributor

Commits on Nov 4, 2025

  1. test commit

    evanrittenhouse committed Nov 4, 2025
    Configuration menu
    Copy the full SHA
    a0cce15 View commit details
    Browse the repository at this point in the history
  2. tokio-quiche: make wait_for_quiche cancellation-safe

    The `wait_for_quiche` future waits for the handshake to generate data.
    Once the handshake has done so, the future will attempt to flush the
    bytes to the network, yielding if the socket isn't writable. Since it's
    called in the `work_loop` `select!` statement, it's subject to
    cancellation if a Quiche timer fires or a packet is received.
    
    The issue is that each iteration of the top-level `work_loop` will call
    `gather_data_from_quiche_conn` at least once, and
    `gather_data_from_quiche_conn` resets the bytes_written counter on each
    call. If the handshake generates data, and a timer/packet resolves the
    `select!` while the socket isn't writable, we'll drop the
    `wait_for_quiche` future without flushing and unconditionally set
    bytes_written back to 0. This means we'll either delay or never send the
    generated handshake data over the network.
    
    This commit splits the flush operation out of the select! arm to make
    the `wait_for_quiche` future cancellation-safe. If a timer/packet
    resolves the `select!`, we must not have written any bytes and are
    therefore good to drop the future. We'll next attempt to generate data
    when we receive a CRYPTO frame or call `send_on_path`.
    evanrittenhouse committed Nov 4, 2025
    Configuration menu
    Copy the full SHA
    f177ade View commit details
    Browse the repository at this point in the history
Loading