c# async await implementation [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported b开发者_开发问答y facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 12 years ago.

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?

---

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.

---

Async/away is a great feature, but I think it's not as well designed as LINQ.

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?

---

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.

---

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