I’ve previously blogged about how to expose existing Asynchronous Programming Model (APM) implementations as Task-based methods. This can be done manually using a TaskCompletionSource<TResult>, or it can be done using the built-in wrapper provided in TPL via the Task.Factory.FromAsync method. By creating a Task-based wrapper for such BeginXx/EndXx method pairs,
Yesterday, I blogged about how you can implement a custom SynchronizationContext in order to pump the continuations used by async methods so that they may be processed on a single, dedicated thread. I also highlighted that this is basically what UI frameworks like Windows Forms and Windows Presentation Foundation do with their message pumps.
I recently saw two unrelated questions, the answers to which combine to form a potentially useful code snippet.
The first question was about SynchronizationContext. SynchronizationContext provides a Post method, which asynchronously schedules the supplied delegate and object state to be executed according to the SynchronizationContext’s whims.
When I discuss the new async language features of C# and Visual Basic, one of the attributes I ascribe to the await keyword is that it “tries to bring you back to where you were.” For example, if you use await on the UI thread of your WPF application,
Recently I’ve heard a number of folks asking about Task.Start, when and when not to use it, how it behaves,and so forth. I thought I’d answer some of those questions here in an attempt to clarify and put to rest any misconceptions about what it is and what it does.