Skip to content
TopicTracker
From devblogs.microsoft.com/oldnewthingView original
TranslationTranslation

Cancellation of Windows Runtime activities is asynchronous

The Windows Runtime cancellation model is asynchronous: calling cancel merely signals the request and returns immediately, without waiting for the operation to actually stop.

Background

- This post is from *The Old New Thing*, a long-running blog by **Raymond Chen** (a senior Microsoft engineer) that digs into Windows internals and quirks. - The **Windows Runtime (WinRT)** is Microsoft's modern API framework for building Windows apps (UWP, WinUI, etc.). - Key point: Cancellation in WinRT is *asynchronous* — when your code requests a cancellation (via a `CancellationToken`), the operation doesn't stop immediately. Instead, the system acknowledges the request and the operation stops *later*, when it gets around to it. You cannot assume the work is done just because the cancellation call returned. - This matters because developers often write sequential code expecting synchronous cancellation, leading to subtle bugs where resources are still in use or callbacks fire after the "cancelled" state is entered.

Related stories

  • Cancellation of Windows Runtime activities is inherently asynchronous, meaning that after requesting cancellation, the operation may not terminate immediately. This requires developers to properly handle the asynchronous nature of cancellation in their code.

  • The article compares three approaches to serving files over HTTP in Linux: synchronous blocking I/O, epoll-based asynchronous I/O, and io_uring. It benchmarks each method using a simple file server, showing that io_uring offers the highest throughput and lowest latency, especially under high concurrency.

  • PHP typically sends HTTP headers only when a script finishes, causing delays for redirects after long operations. The article notes this issue and mentions that complex workarounds exist for sending headers before script completion.