async-ctp

Consider this, Task task = new Task (async () =>{ await TaskEx.Delay(1000); }); task.Start(); task.Wait(); The call task.Wait() does not wait for the task completion and the next line is executed immediately, but if I wrap the async lambda expression into a method call, the code works as expected. private static async Task AwaitableMethod() { await TaskEx.Delay(1000); } then (updated according comment from svick) await AwaitableMethod(); In your lambda example, when you call task.Wait() , you are waiting on the new Task that you constructed, not the delay Task that it returns. To get your

During the Techdays here in the Netherlands Steve Sanderson gave a presentation about C#5, ASP.NET MVC 4, and asynchronous Web . He explained that when requests take a long time to finish, all the threads from the threadpool become busy and new requests have to wait. The server can't handle the load and everything slows down. He then showed how the use of async webrequests improves performance because the work is then delegated to another thread and the threadpool can respond quickly to new incoming requests. He even demoed this and showed that 50 concurrent requests first took 50 * 1s but

I tried to use the SwitchTo method today to switch to the GUI thread, and found that the example I lifted it from does not work, simply because the method is not there. I then found this blurb here : The reason we got rid of it was because it was so dangerous. The alternative is to bundle up your code inside TaskEx.Run... My question is simply: Why was it dangerous? What specific dangers would using it lead to? Note that I did read the rest of that post, so I do understand there are technical limitations here. My question is still, if I'm aware of this, why is it dangerous ? I am considering

Client iGame Channel = new ChannelFactory<iGame> ( new BasicHttpBinding ( BasicHttpSecurityMode . None ) , new EndpointAddress ( new Uri ( "http://localhost:58597/Game.svc" ) ) ) . CreateChannel ( ); public Task<SerializableDynamicObject> Client ( SerializableDynamicObject Packet ) { return Task<SerializableDynamicObject> . Factory . FromAsync ( Channel . BeginConnection , Channel . EndConnection , Packet , null ); } Contract [OperationContract ( AsyncPattern = true )] IAsyncResult BeginConnection ( SerializableDynamicObject Message , AsyncCallback Callback , object State );

Browsing through the channel 9 msdn videos I found the following unanswered comment and was hoping someone could possibly explain it? I dont get the point of the async keyword. Why not just allow the await keyword anytime the method returns Task, just like iterators can yield return on any method that returns an IEnumerable. I'm sure there is a good reason, I'd just like to understand why the above suggestion was not possible. It was introduced mainly to avoid backward compatibility issues. If the async -ness of a method must be inferred by the compiler (that would be through the detection of

In looking at various C# Async CTP samples I see some async functions that return void , and others that return the non-generic Task . I can see why returning a Task<MyType> is useful to return data to the caller when the async operation completes, but the functions that I've seen that have a return type of Task never return any data. Why not return void ? SLaks and Killercam's answers are good; I thought I'd just add a bit more context. Your first question is essentially about what methods can be marked async . A method marked as async can return void , Task or Task<T> . What are the

Could someone please be kind enough to confirm if I have understood the Async await keyword correctly? (Using version 3 of the CTP) Thus far I have worked out that inserting the await keyword prior to a method call essentially does 2 things, A. It creates an immediate return and B. It creates a "continuation" that is invoked upon the completion of the async method invocation. In any case the continuation is the remainder of the code block for the method. So what I am wondering is, are these two bits of code technically equivalent, and if so, does this basically mean that the await keyword is