"await"
Progress is being made on our support for Metro, Visual Studio 11 and .NET 4.5 integration, on many levels. One exciting new language feature in Oxygene for both Metro and the regular .NET 4.5 framework is support for the new “await” keyword that is also coming to C#.
Simply put, “await” lets you use the result of an asynchronous operation (such as the result of many of Metro’s and .NET 4.5 new APIs) or — only in Oxygene — an async future, and have the resulting code be “wrapped around” to run asynchronously, as well.
In Oxygene, when you access a async future‘s value, your code will block right there, and wait for the future to complete before it continues executing — after all you’re using the value, and that value has to come from somewhere.
Using the “await” keyword, your code will look and work much the same as without, except your code will not block. Instead, all parts of the code that depend on the future value (or otherwise precede your accessing it) will be extracted and moved into a separate block of code that runs asynchronously.
This is best seen with a concrete example, so consider the following code:
| method MainForm.CountFiles(aStartFolder: String): Int32;beginresult:= Directory.GetFiles(aStartFolder).Length;foreach d in Directory.GetDirectories(aStartFolder)doresult:=result+CountFiles(d);end; method MainForm.button1_Click(sender: System.Object; e: System.EventArgs);beginvar x :=async CountFiles('C:\'); MessageBox.Show('You have '+(await x)+' files.');end; |
The async future, on its own, has the potential of making the the count asynchronous, but the following “MessageBox.Show” would block right away, making the use of the future essentially useless. Complex code could be written to wait for the future and then trigger the message box from a different place in code.
But “await” takes care of all that; it allows you to write code using the “naïve” approach without worrying about application flow. You can concentrate on your application logic, and the complexities of threading (and synchronization of results back to the main thread) are handled for you.
So what happens when you run this? Easy: when you click the button, our async future is created and started, causing the (recursive) call to CountFiles. Once that is up and running, the event handler is done and returns control to your application. Now the future is running in the background, counting files, and probably taking a few minutes to do it, depending on your harddisk size.
Once the future is complete, the message string is assembled and “MessageBox.Show” is called to display it — also on the main thread, synchronized via the application’s message loop.
All this time, your application remains responsive! As a matter of fact, in the example above, i could go ahead and click the button several times, launching a handful of independent file scans (which of course makes little sense in this scenario — a real app could disable the one button, or might let you scan different folders at the same time, getting the path from an edit field) that run in parallel, and will each eventually respond with a message box, one by one.