Take the 2-minute tour ×

I have some doubts about the design of C#'s upcoming async/await feature.

  1. The convenience of attaching the new mechanism to Task<T>
  2. I think is better to use async substituting the await keyword. For expaple: var result = async GetResultAsync();
  3. The mechanism to cancel a ongoing async operation using a token is not as elegant as I feel it could be.

Async/away is a great feature, but I think it's not as well designed as LINQ. Also, I feel the desing team is dangerously pleased with the current design; and might not take community feedback into account.

What do you think?

share|improve this question

closed as not constructive by Chris Smith, Henk Holterman, SolutionYogi, Jeff Mercado, Mark Cidade Feb 6 '11 at 22:05


Voting to re-open after Eric's response. There's an emperor and clothes problem here, the question is inconvenient but real. –  Hans Passant Feb 6 '11 at 22:28
Hans Passant, I apreciate your support. But sadly I'm not Eric Lippert. –  Masterile Feb 6 '11 at 23:46
add comment

4 Answers

up vote 6 down vote accepted


What aspects of the design process do you feel are deficient compared to the design process for LINQ?

Also, I feel the design team is dangerously pleased with the current design; and might not take community feedback into account.

What gives you that impression? We've been inviting community feedback for quite some time now. It is not being ignored.

What do you think?

I think this is a discussion question and not an engineering question. Are you sure this is the right site for this question?

share|improve this answer
Not quite the right site for this answer either? An engineer's answer would fit well. I personally think the CancellationToken is grossly neglected in most any example I've seen. Setting that wheel in motion and keeping your fingers crossed behind your back that it will come to a good end is 90% of the real world problems with async code. But yes, hard to introduce the what-ifs on an otherwise great alternative to explicit state machines. It's still shiny. I'd enjoy a blog post about ways to use the async feature without the CancellationToken in real code. Think Form or Window. –  Hans Passant Feb 6 '11 at 22:24
Eric, thanks for your answer. The last question was in relation with the concrete 3 points I mention. –  Masterile Feb 6 '11 at 22:30
I love c# becouse I consider it to be a very well desined programming language. It's becouse of that, I espect the most from the c# team. I mention several concrete tecnical points that seems to be very argumentative. To me is ridiculous but I repect your opinion. StackOverflow users right to censor such a "subjective" question, it's his own right. But I get very disappointed becouse of that. –  Masterile Feb 8 '11 at 21:12
@Masterile: this is not a discussion board for arguing about the pros and cons of various technologies; it is a question-and-answer site for specific questions about engineering problems. If you want to provide feedback or have a discussion about the merits of the task asynchrony pattern in C# and VB, there is a specific site just for that: social.msdn.microsoft.com/Forums/en-US/async. That is the appropriate place to have this discussion. –  Eric Lippert Feb 8 '11 at 22:25
Thanks for the response –  Masterile Feb 9 '11 at 0:50
add comment

These kind of design decisions tend to make little sense until you've tried to make this work yourself. Your assignment: write asynchronous code and make it stop whenever you want to. Your constraints: you cannot use Thread.Abort() and can never cause deadlock.

share|improve this answer
add comment
  1. They have already invested a lot of work into Task and Task<T>, which is designed to perfectly fit this situation. I find this very convenient, because I precisely know what to expect of a Task - having it used previously - and I think a lot of other developers will also feel that way. In my opinion it's a lot better than introducing something new - and I'm not even sure what could be different that would make a new type more up to the task. Do you have any concrete ideas?

  2. I think that you're missing the purpose of the async keyword. It is used to mark methods that will be (partially) executed asynchronously (when you use the await keyword). It is required for the compiler to know which methods to "perform magic on"; it doesn't "convert" a method to be executed asynchronously. For that you should use ThreadPool.QueueUserWorkItem.

  3. I can't really comment on this. What would be a more elegant solution in your opinion? I'm sure Microsoft will take your feedback into consideration if you share it with them.

share|improve this answer
I refer to use the same keyword (async) in both places, in the signature and in the method body. –  Masterile Feb 6 '11 at 22:42
The cancellation solution could be something similar to F# implicit cancellation. –  Masterile Feb 7 '11 at 1:15
add comment

Start reading: http://blogs.msdn.com/b/ericlippert/archive/2010/10/28/asynchrony-in-c-5-part-one.aspx

share|improve this answer
I have already read all these post. Thanks!! –  Masterile Feb 6 '11 at 22:39
add comment
