C# is one of those beautiful languages which seems to evolve into the most gracious programming languages. With the introductions of the
async keywords introduced in C# 5.0, parallel programming just got a lot easier. It builds the language feature on top of the excellent
System.Threading.Tasks namespace implemented from .NET 4.0+ versions.
To compliment the new
await keyword, the .NET 4.5 framework ships with additional methods named
xxxAsync. For reasons beyond the scope of this blog post, these new
xxxAsync methods will return a
Task<TResult>. The BCL team did an excellent job of implementing methods like these on the very commonly used classes which would benefit from parallel programming, such as the
However, not all the classical
IAsyncResult has an equivalent
xxxAsync method which returns a
Task<TResult>. One such example is the raw
Socket class - using the
await pattern on such a class would definitely assist bringing down the bug count since the programmer does not have to manage the delicate callback mechanisms.
The good news is that there is a provision to convert those
IAsyncCallback “contracts” into “awaitable” code. They can be wrapped by following methods.
An example usage of the two methods:
There are a couple of notes in the above code illustrations.
beginMethoddelegate accepts parameters (commented with “(1)”), it elegantly accepts the parameter values latter on after the
endMethodparameter (commented with “(2)”). At least you do not have to write wrapping anonymous delegates.
I used the default
Task<TResult>because there is not a good reason to have a seperate scheduler for your TPL code.
So, there it is: an elegant way to wrap those classical
IAsyncCallback code into the cool
awaitable code, even in the absence of the baked in