Don't use callbacks when performing sync IO with async handles#126845
Open
Copilot wants to merge 13 commits into
Open
Don't use callbacks when performing sync IO with async handles#126845Copilot wants to merge 13 commits into
Copilot wants to merge 13 commits into
Conversation
…vent for sync IO with async handles Instead of using ThreadPoolBoundHandle callbacks and reference counting when performing synchronous IO with async file handles, allocate the NativeOverlapped directly via NativeMemory and set the low-order bit of hEvent to suppress I/O completion port notifications. This eliminates the CallbackResetEvent class, the s_callback field, and the AllocateCallback/GetNativeOverlappedForAsyncHandle methods, reducing allocations and complexity. Agent-Logs-Url: https://github.com/dotnet/runtime/sessions/d7a61400-c63f-401a-9503-0313459af6f7 Co-authored-by: adamsitnik <6011991+adamsitnik@users.noreply.github.com>
Copilot
AI
changed the title
[WIP] Remove callbacks for sync IO operations with async handles
Don't use callbacks when performing sync IO with async handles
Apr 13, 2026
Contributor
|
Tagging subscribers to this area: @dotnet/area-system-io |
adamsitnik
reviewed
Apr 14, 2026
Member
adamsitnik
left a comment
There was a problem hiding this comment.
@copilot please address my feedback (nits)
…appedWithEventHandle Agent-Logs-Url: https://github.com/dotnet/runtime/sessions/bcdd8838-718e-4561-abf4-90c9c2deb905 Co-authored-by: adamsitnik <6011991+adamsitnik@users.noreply.github.com>
- Cache ManualResetEvent (not raw nint) in SafeFileHandle using Interlocked rent/return pattern - Use public ManualResetEvent ctor, Reset() on reuse to ensure non-signaled state - Use WaitOne() to respect SynchronizationContext - When WaitOne throws, cancel pending IO with CancelIoEx + GetOverlappedResult(bWait:true) before freeing overlapped - Add test demonstrating SynchronizationContext.Wait exception scenario Co-authored-by: adamsitnik <6011991+adamsitnik@users.noreply.github.com>
adamsitnik
reviewed
Jun 8, 2026
Member
adamsitnik
left a comment
There was a problem hiding this comment.
@copilot address my feedback
…usability after failure Co-authored-by: adamsitnik <6011991+adamsitnik@users.noreply.github.com>
adamsitnik
reviewed
Jun 8, 2026
Member
adamsitnik
left a comment
There was a problem hiding this comment.
@copilot address my feedback
Co-authored-by: adamsitnik <6011991+adamsitnik@users.noreply.github.com>
Co-authored-by: adamsitnik <6011991+adamsitnik@users.noreply.github.com>
Contributor
Author
adamsitnik
approved these changes
Jun 8, 2026
Member
There was a problem hiding this comment.
The changes LGTM, the perf is much better despite still using ManualResetEvent:
(managed_cached is the PR)
BenchmarkDotNet v0.16.0-nightly.20260302.459, Windows 11 (10.0.26200.8390/25H2/2025Update/HudsonValley2)
AMD Ryzen Threadripper PRO 3945WX 12-Cores 3.99GHz, 1 CPU, 24 logical and 12 physical cores
Memory: 63.86 GB Total, 32.62 GB Available
.NET SDK 11.0.100-preview.5.26255.101
[Host] : .NET 11.0.0 (11.0.0-preview.5.26255.101, 11.0.26.25601), X64 RyuJIT x86-64-v3| Method | Toolchain | fileSize | userBufferSize | options | Mean | Ratio | Allocated |
|---|---|---|---|---|---|---|---|
| Read | \main\corerun.exe | 1024 | 1024 | None | 145.7 us | 1.00 | 4360 B |
| Read | \main\corerun.exe | 1024 | 1024 | Asynchronous | 173.9 us | 1.00 | 4576 B |
| Read | \managed_cached\corerun.exe | 1024 | 1024 | Asynchronous | 156.9 us | 0.90 | 4464 B |
| Read | \native_cached\corerun.exe | 1024 | 1024 | Asynchronous | 154.6 us | 0.89 | 4440 B |
| Write | \main\corerun.exe | 1024 | 1024 | None | 609.2 us | 1.00 | 4360 B |
| Write | \main\corerun.exe | 1024 | 1024 | Asynchronous | 639.3 us | 1.00 | 4577 B |
| Write | \managed_cached\corerun.exe | 1024 | 1024 | Asynchronous | 627.9 us | 0.98 | 4465 B |
| Write | \native_cached\corerun.exe | 1024 | 1024 | Asynchronous | 623.3 us | 0.98 | 4441 B |
| Read | \main\corerun.exe | 1048576 | 512 | None | 779.2 us | 1.00 | 4361 B |
| Read | \main\corerun.exe | 1048576 | 512 | Asynchronous | 2,756.3 us | 1.00 | 49460 B |
| Read | \managed_cached\corerun.exe | 1048576 | 512 | Asynchronous | 1,262.3 us | 0.46 | 4466 B |
| Read | \native_cached\corerun.exe | 1048576 | 512 | Asynchronous | 1,113.6 us | 0.40 | 4442 B |
| Write | \main\corerun.exe | 1048576 | 512 | None | 7,438.8 us | 1.00 | 4365 B |
| Write | \main\corerun.exe | 1048576 | 512 | Asynchronous | 7,788.8 us | 1.00 | 49470 B |
| Write | \managed_cached\corerun.exe | 1048576 | 512 | Asynchronous | 7,507.1 us | 0.96 | 4473 B |
| Write | \native_cached\corerun.exe | 1048576 | 512 | Asynchronous | 7,387.7 us | 0.95 | 4449 B |
| Read | \main\corerun.exe | 1048576 | 4096 | None | 709.8 us | 1.00 | 241 B |
| Read | \main\corerun.exe | 1048576 | 4096 | Asynchronous | 2,929.2 us | 1.00 | 45340 B |
| Read | \managed_cached\corerun.exe | 1048576 | 4096 | Asynchronous | 1,235.6 us | 0.42 | 346 B |
| Read | \native_cached\corerun.exe | 1048576 | 4096 | Asynchronous | 1,049.8 us | 0.36 | 322 B |
| Write | \main\corerun.exe | 1048576 | 4096 | None | 7,197.4 us | 1.00 | 245 B |
| Write | \main\corerun.exe | 1048576 | 4096 | Asynchronous | 7,838.3 us | 1.00 | 45350 B |
| Write | \managed_cached\corerun.exe | 1048576 | 4096 | Asynchronous | 7,351.9 us | 0.94 | 353 B |
| Write | \native_cached\corerun.exe | 1048576 | 4096 | Asynchronous | 7,477.0 us | 0.96 | 329 B |
| Read | \main\corerun.exe | 104857600 | 4096 | None | 82,969.7 us | 1.00 | 352 B |
| Read | \main\corerun.exe | 104857600 | 4096 | Asynchronous | 329,198.7 us | 1.00 | 4506328 B |
| Read | \managed_cached\corerun.exe | 104857600 | 4096 | Asynchronous | 154,884.8 us | 0.47 | 568 B |
| Read | \native_cached\corerun.exe | 104857600 | 4096 | Asynchronous | 118,937.8 us | 0.36 | 544 B |
| Write | \main\corerun.exe | 104857600 | 4096 | None | 172,746.9 us | 1.00 | 464 B |
| Write | \main\corerun.exe | 104857600 | 4096 | Asynchronous | 458,918.6 us | 1.00 | 4506328 B |
| Write | \managed_cached\corerun.exe | 104857600 | 4096 | Asynchronous | 208,779.5 us | 0.46 | 792 B |
| Write | \native_cached\corerun.exe | 104857600 | 4096 | Asynchronous | 170,257.2 us | 0.37 | 768 B |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
When performing synchronous I/O on async file handles (
FILE_FLAG_OVERLAPPED),RandomAccess.Windows.cspreviously usedThreadPoolBoundHandle.UnsafeAllocateNativeOverlappedwith anIOCompletionCallbackand a customCallbackResetEventclass that tracked a reference count to handle the race between the IOCP callback and the caller'sGetOverlappedResult.This callback path is unnecessary. Setting the low-order bit of
hEventin theOVERLAPPEDstructure prevents the I/O completion from being queued to the completion port, eliminating the callback.Changes:
NativeOverlappedviaNativeMemory.AllocZeroedinstead ofThreadPoolBoundHandleEventHandle = handle | 1to suppress IOCP notificationManualResetEventinSafeFileHandleusing anInterlockedrent/return pattern (following the existing_reusableOverlappedcaching pattern inSafeFileHandle.OverlappedValueTaskSource.Windows.cs) to avoid creating/disposing an event on every sync I/O callManualResetEvent.WaitOne()only forERROR_IO_PENDING(notERROR_SUCCESS) to respectSynchronizationContextand COM message pumping while avoiding unnecessary waitsWaitOne()throws arbitrary exceptions (e.g., viaSynchronizationContext): catch any exception, cancel the pending I/O withCancelIoEx, then wait for completion viaGetOverlappedResult(bWait: true)before freeing the overlappedNativeMemory.Freeand return cached event infinallys_callback,AllocateCallback(),GetNativeOverlappedForAsyncHandle(), andCallbackResetEventEnsureThreadPoolBindingInitialized()from sync-over-async paths (no longer usesThreadPoolBoundHandle)overlapped->InternalLow = IntPtr.Zeroin EOF path (only needed forThreadPoolBoundHandle.FreeNativeOverlappedassertion, notNativeMemory.Free)GetLastWin32ErrorAndDisposeHandleIfInvalidwhenReadFile/WriteFilereturns failure (0), and treat synchronous completion asERROR_SUCCESS(avoids using undefined/staleGetLastErrorvalues)ThrowingSynchronizationContexttest to demonstrate exceptions fromWaitOne()are handled safely without memory corruptionSafeFileHandle.CreateAnonymousPipe(..., asyncRead: true, asyncWrite: false)so pending I/O is exercised deterministically, and verify the handle remains usable for subsequent reads with content validation after the failure pathThis reduces allocations and complexity, preserves managed wait behavior, fixes a potential use-after-free when
WaitOnethrows viaSynchronizationContext, and fixes incorrect error handling when overlapped operations complete synchronously.