An async operation that cannot be stopped is a resource leak with good manners. CancellationToken is how .NET stops them, and it is cooperative: nothing is aborted, nothing is interrupted. The operation checks, and gives up. That cooperation is the part people underuse, and the details around it are the part people get wrong. The two halves CancellationTokenSource is the control. CancellationToken is the… [read more]

IDisposable.Dispose returns void. That is fine when cleanup means releasing a handle, and a problem when it means flushing a buffer to disk or sending a close frame over a socket. Those are I/O, and a void method has only two ways to do I/O: block a thread, or fire and forget. IAsyncDisposable exists to give cleanup somewhere to await. The interface public interface IAsyncDisposable { ValueTask… [read more]

An async method produces one value. An iterator produces many values but cannot await. IAsyncEnumerable<T> is what happens when you need both, and the compiler builds it by fusing the two state machines it already knows how to generate. The typical case is paging through an API: each page is a network call, and the caller should not have to know that pages exist. await foreach (var item in… [read more]

ValueTask<T> is the return type people reach for when they have heard that Task allocates, and then use everywhere. That is the wrong lesson. ValueTask solves one specific problem, it solves it very well, and it comes with rules that Task does not have. What it is ValueTask<T> is a struct holding one of three things: a TResult directly, for a synchronous success, a Task<TResult>, for the asynchronous… [read more]

The previous post covered ExecutionContext, which decides what state a continuation sees. This post is about the other thing await captures, which decides where the continuation runs. It is also the mechanism behind the single most famous bug in async C#: calling .Result and hanging forever. What a SynchronizationContext is A SynchronizationContext is an abstraction over "post this callback to the right… [read more]

The thread that resumes after an await is usually not the thread that started the method. That is the whole point, and it creates a problem: anything you attached to the thread is gone. [ThreadStatic] private static string? CurrentUser; CurrentUser = "alice"; await SomethingAsync(); // CurrentUser may be null here ExecutionContext is the mechanism that solves this. It is the thing that flows across an… [read more]

The post on the compiler rewrite pulled an async method apart and found a generated struct with a MoveNext method. One field in that struct was left unexplained: public AsyncTaskMethodBuilder<int> <>t__builder; The builder is the other half of the machinery. The state machine knows where it is; the builder knows what to hand back to the caller and how to get running again. It is also the piece you can… [read more]

The previous post built a MyTask that can start work and report that it finished. It cannot stop anything. That gap is not an oversight in the implementation: stopping is a separate concern, and .NET models it as a separate pair of types. This post builds those too. MyCancellationTokenSource and MyCancellationToken, from scratch, and then wires them into MyTask. The implementation is short. The design… [read more]

The previous post decompiled an async method and showed the state machine the compiler generates. That state machine calls GetAwaiter, reads IsCompleted, registers a continuation, and eventually completes a Task. Every one of those calls lands on code that somebody wrote. This post writes it. MyThreadPool and MyTask, from nothing, in about 150 lines that actually run. Not a simplification of the real… [read more]

async and await are not runtime features up to .NET 10. They are a compiler rewrite. When you mark a method async, the C# compiler removes the method body, moves it into a generated type, and replaces the original method with a few lines that create and start that type. Everything else, the scheduling, the exception handling, the value that eventually lands in the returned Task, is ordinary code you could… [read more]