async-ctp

I was watching a vid about Async CTP and saw that if you call await from e.g. main thread , then the execution will continue from main thread when the work is completed. e.g //called from main thread var result = await SomeAsyncWork(); //this will execute in main thread also console.writeline(result) I had the naive impression that there would be a normal call back going on which would be executed on a worker thread. At some level that must be what is going on since you can wrap normal async methods in a Task of T with Task.FromAsync but normal async methods will run in worker threads, so how

How would you implement something that works similarly to the Async CTP await keyword? Is there a simple implementation that works like await in all cases, or does await require different implementations for different scenarios? await always involves the same kind of transformation - but it's a pretty painful one. The library side of await isn't too complicated, but the tricky bit is that the compiler builds a state machine for you, allowing the continuation to jump back to the right place. It's possible that my some hacky use of iterator blocks (yield return) you could fake something similar.

What is the recommended way for adding postconditions to async methods which return Task<T> ? I have read the following suggestion: http://social.msdn.microsoft.com/Forums/hu-HU/async/thread/52fc521c-473e-4bb2-a666-6c97a4dd3a39 The post suggests implementing each method as synchronous, contracting it, and then implementing an async counterpart as a simple wrapper. Unfortunately I don't see this as a workable solution (perhaps through my own misunderstanding): The async method, although assumed to be a wrapper for the sync method, is left without any real code contract and can therefore do as

In .NET 4, is there any functional equivalent to .NET 4.5's System.Threading.Tasks.Task.WhenAll() ? The goal is to wrap up multiple async tasks into a single one that is completed when all of its constituent tasks are done. I think the closest thing built-in in .Net 4.0 is ContinueWhenAll() . You can make the continuationAction a simple tasks => tasks and use the returned Task . For performance reasons, you might want to use it with TaskContinuationOptions.ExecuteSynchronously . In .NET Framework 4.0 WhenAll and WhenAny can be used with installed AsyncCTP in case of Visual Studio 2010 or Async

I'm trying to understand when to use TaskEx.Run . I have provided two code sample i wrote below that produce the same result. What i fail to see is why i would take the Task.RunEx TaskEx.RunEx approach, I'm sure there is a good reason and was hoping someone could fill me in. async Task DoWork(CancellationToken cancelToken, IProgress<string> progress) { int i = 0; TaskEx.RunEx(async () => { while (!cancelToken.IsCancellationRequested) { progress.Report(i++.ToString()); await TaskEx.Delay(1, cancelToken); } }, cancelToken); } private void Button_Click(object sender, RoutedEventArgs e) { if

What if you need to run multiple asynchronous I/O tasks in parallel but need to make sure that no more than X I/O processes are running at the same time; and pre and post I/O processing tasks shouldn't have such limitation. Here is a scenario - let's say there are 1000 tasks; each of them accepts a text string as an input parameter; transforms that text (pre I/O processing) then writes that transformed text into a file. The goal is to make pre-processing logic utilize 100% of CPU/Cores and I/O portion of the tasks run with max 10 degree of parallelism (max 10 simultaneously opened for writing

So the new async CTP is very cool; it makes my life a lot easier not having to write named callback methods and makes the intent of the methods a lot clearer. Now that I've gotten to play with it a little, I'm wondering what differences there may be between the async/await and the "classic" asynchronous callback syntaxes. Here are a few questions I have in mind, but there are numerous others that I won't have thought of now and probably will later. Does one perhaps offer superior performance over the other? Is there an overhead to one that is greater than the other? Which would be better to