Skip to content

fix(windows): join the async reader before releasing the adapter - #6

Merged
KKRainbow merged 1 commit into
v2from
fix/windows-async-close
Oct 14, 2026
Merged

KKRainbow merged 1 commit into
v2from
fix/windows-async-close

Conversation

@KKRainbow

@KKRainbow KKRainbow commented Oct 13, 2026 •

Copy link
Copy Markdown
Member

Dropping a Windows AsyncDevice could return while its blocking reader still owned the Wintun session and adapter. An immediate same-name restart could then reopen that adapter before teardown finished, producing ERROR_ALREADY_INITIALIZED or racing adapter removal.

Close the packet receiver, signal session shutdown, and join the reader before releasing the final session reference. Closing the channel also lets the worker exit when the receive ring stays busy. A closed channel during teardown is no longer logged as an error.

Validation on Windows 11 build 22621 with Wintun 0.14.1:

  • Before the fix, a 100-cycle async close/recreate probe failed 24 times without a requested GUID and 18 times with a fixed GUID. The synchronous control passed.
  • The added ignored regression test passed 100 consecutive same-name/fixed-GUID recreations while another adapter remained active. It also checks that no session reference survives device drop.
  • cargo fmt --all -- --check passed.
  • Windows Clippy passed with the existing io_other_error, needless_lifetimes, and useless_conversion lints allowed. Unfiltered -D warnings is blocked by pre-existing findings in error.rs, address.rs, and Windows platform code; this patch does not change those files.

EasyTier/EasyTier#2694 pins this commit and removes the random adapter-name workaround. Related: EasyTier/EasyTier#110 and EasyTier/EasyTier#2682.

Close-latency measurements on the same Windows 11 VM (release build, x86_64-pc-windows-gnu, 4 MiB rings, 30 samples per version/scenario):

Scenario Old drop median (ms) Fixed drop median (ms) Fixed P95 (ms) Fixed maximum (ms)
Idle reader 0.010 71.058 96.206 99.792
Continuous traffic 0.009 32.983 40.975 158.805
Queued packets (~19k) 3.930 36.032 39.979 41.460

The timer encloses only drop(AsyncDevice), excluding adapter creation, address configuration, and workload setup. The traffic case consumed roughly 66k packets/s; the backlog case left 16.8k–22.3k packets queued in the fixed build. The sender continued running during drop. Old drop can return while its detached worker is still performing teardown, which explains its lower return latency.

An additional diagnostic experiment kept one session reference until after device drop, separating worker/queue cleanup from final session/adapter release (10 samples per scenario). Median worker/queue cleanup was 0.095 ms idle, 0.213 ms under continuous traffic, and 3.143 ms with backlog. Final session/adapter release medians were 67.748, 29.861, and 30.724 ms respectively. This identifies final resource release as the main observed cost. The sender was stopped before the separately timed final release.

All 180 full-drop samples and 30 split samples passed. No measured close reached one second. These finite measurements on one VM do not establish a hard upper bound: the synchronous thread join still has no timeout. Benchmark instrumentation was confined to test-only source copies; this PR implementation was unchanged.

Dropping AsyncDevice used to detach the blocking reader thread. Its
session reference could keep the old adapter alive after drop returned,
so immediately reopening the same name raced session teardown.

Close the packet receiver, signal shutdown and join the reader before
releasing the remaining session reference. Closing the receiver also
stops a reader that is continuously receiving packets. Treat its closed
channel as normal shutdown.

Add an opt-in Windows regression test that recreates a fixed-name,
fixed-GUID adapter 100 times while another adapter remains active and
checks that each dropped device releases every session reference.

Validation: the regression test passes on Windows 11 with Wintun 0.14.1;
cargo fmt --all -- --check passes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant