# Asynchronous I/O and the Bytes a Cancelled Write Keeps

> The latest verified candidate passes focused 64-bit read and write profiles on both pipe routes. The tests caught real EOF, completion-block, and cancellation-accounting mistakes.

Canonical page: https://pyrosoft.pro/blog/async-io-and-the-bytes-a-cancelled-write-keeps

Live development journal; no publication date.
Work period: 2026-10-11 to 2026-10-11
Updated: 2026-10-20

A file operation doesn't always finish before the function returns. The application may need to keep running, wait for an event, or cancel the request later. That means the port has to preserve the request's data and ownership until completion, even if the caller closes a handle or changes its memory in the meantime.

The latest verified 64-bit candidate now passes focused read and write profiles on both the shared named-FIFO and private-pipe routes. The tests check pending operations, completion events, file waits, cancellation, duplicate and last-handle close behavior, and protection against writing into a freed and reused read buffer.

Several real mistakes came out of those tests. One Darwin FIFO route didn't report peer closure through the readiness mechanisms first tried. Another review, using Wine's Windows conformance tests, showed that the native NT call should leave the caller's completion block unchanged while the request is pending. The earlier synthetic expectation had been wrong, so both the implementation and the test contract needed correction.

The write-cancellation bug was especially concrete. A large write had already sent a prefix of its data to the peer. Cancelling it produced a completion that claimed zero bytes had transferred. The receiver disagreed: it had the exact bytes. The correction keeps the host-accepted byte count for cancelled writes, and the test compares that count with the full prefix actually received.

The host engine passes 20 cases in each of two builds: normal ARM64 and ThreadSanitizer, for 40 case runs. The Windows write profiles pass on both routes, and the existing read profiles were repeated on that exact rebuilt driver. These are functional results for the tested profiles, not performance numbers or a complete Windows asynchronous-I/O claim.

The next 32-bit bridge has a different requirement: its completion block is eight bytes, and its addresses belong to the guest window. An owned completion target is proposed so the worker won't retain temporary thunk-stack storage. That proposal is still uncompiled, unreviewed, and unadopted. It doesn't belong in the passing-results column yet.

OVERLAPPED I/O, completion ports, guest-thread callbacks, lifetime races, and broader regressions remain open. So do full Windows application and game sessions, Intel Mac framework integration, the graphical launcher workflow, and signed clean-machine distribution. The latest tested code remains a development candidate rather than the adopted product baseline.

What I want to keep from this increment is the way the evidence got better. We checked what the receiver actually received, preserved the old failing result, and reran related behavior on the fixed build. That's useful progress we can build on without bringing back a completion percentage the project can't support.