on a related news, http://www.everything.net , records a sudden surge in traffic.
Everything .NET programmers know about Asynchronous Programming is wrong
31–40 of 57 posts
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#32Genuine question... We have way over a million lines of c#, in asp.net, mvc and windows forms. We get 80,000,000 http requests a day. We have no async (delegates or 4.5 stuff), no threading other than what WCF, AppFabric and ASP.Net give us. About 25% is generic CRUD code but the rest is complicated matching, integration and math code. We also touch most fundamental computer science domains. This begs the question: y…
I didn't really get it until I watched Ander's original keynote on it.
To appreciate async and await, you have to go through the exercise of converting some synchronous code to an event driven model with callbacks. Then do it using async/await. It's more syntactic sugar than anything.
I appreciate it in how I appreciate the dynamic keyword. I know how to dynamically Invoke() methods at runtime using reflection. It's a lot of boilerplate and ceremony, and the dynamic keyword helps alleviate that.
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#33.NET != ASP.NET
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#34Genuine question... We have way over a million lines of c#, in asp.net, mvc and windows forms. We get 80,000,000 http requests a day. We have no async (delegates or 4.5 stuff), no threading other than what WCF, AppFabric and ASP.Net give us. About 25% is generic CRUD code but the rest is complicated matching, integration and math code. We also touch most fundamental computer science domains. This begs the question: y…
Just fyi, you're raising the question, not begging it.
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#35Earlier quoted context omitted.
> This begs the question: you really need async in the language? Or even delegates. Or interfaces. Or LINQ. Basically you could write the same thing in C. Or assembly.
Strawman. The parent isn't arguing that the new async constructs in the language don't make asynchronous programming easier. He's questioning the need for using asynchronous programming models at all, for the common use case of ASP.NET applications.
>The parent isn't arguing that the new async constructs in the language don't make asynchronous programming easier.
He's questioning the need for using asynchronous programming models at all, for the common use case of ASP.NET applications.
And, my comment questions this very idea that for language constructs to be added there has to be a "need".
They is never a hard need. We can do everything with assembly.
Language constructs are added to make things easier.
And that includes ASP.NET applications. His might not have a use for patterns made easier by async, but others do, especially those doing real time websockety stuff.
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#36Earlier quoted context omitted.
When you say that a background task should be made into a RESTful API call, I assume you mean that instead of spinning up a local thread to do the work you should defer it to another service. Certainly you can do that, but async/await is still relevant in that case. The key question is: while said REST call is happening, what is the caller doing? Normally, he's sitting there and blocking his thread until the call fin…
Your point is a good one. Without wanting to get too deep into a design for some hypothetical system, I guess I was thinking that I'd either try and modify the current request such that it can return something to its caller (e.g. Render a web page saying "Loading..." with a setTimeout call in it). Or use .NET's HTTP request library which has a delegate callback option that lets you get on with other stuff.
The problem with delegate/callback patterns with API calls is that you end up having to preserve a lot of state manually, which can be an error-prone process. Any metadata associated with a request must be persisted (and then read back) in painstakingly manual fashion with a delegate pattern, whereas with async (or closures, or...) this information is trivially available on your stack.
The nice thing about async vs. typical closures is that it neatly avoids a lot of nested scopes.
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#37The single biggest problem I have with async/await in C# is how it requires an act of god to call an async(await) method from a non-async method. And even then, wrapping exceptions and such is a huge pain as well.
I would love async if it was completely optional and I could call async code from a synchronous context. Like if I could just say `var tmp=await Foo();` within a synchronous method (and it just ran Foo on the current thread and blocked)..
Instead, it requires one of the methods outlined here: http://stackoverflow.com/questions/5095183/how-would-i-run-a...
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#38The problem that I keep seeing is people think that TPL or Async/Await heck, even Rx is a Threading library.... As a result people still use monitors or any kind of blocking wait event. Including the TaskCompletetionSource in the framework I don't think helped this. A lot of what I've seen on different projects using these newer tools is an attempt to re-create what they would do before. Doing a Producer Consumer, th…
What's wrong with TaskCompletionSource? I use it constantly. It's great for translating other async styles (like passing a callback as the last argument) into tasks.
How would you implement Observable.LastAsync, without using something equivalent to TaskCompletionSource along the way?
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#39The problem that I keep seeing is people think that TPL or Async/Await heck, even Rx is a Threading library.... As a result people still use monitors or any kind of blocking wait event. Including the TaskCompletetionSource in the framework I don't think helped this. A lot of what I've seen on different projects using these newer tools is an attempt to re-create what they would do before. Doing a Producer Consumer, th…
What's wrong with TaskCompletionSource? I use it constantly. It's great for translating other async styles (like passing a callback as the last argument) into tasks. How would you implement Observable.LastAsync, without using something equivalent to TaskCompletionSource along the way?
I think your parent is arguing that, despite TaskCompletionSource exists, some people still don't use it much and resort to callbacks (presumably because they have not learned about it).
As in “adding TaskCompletionSource to the framework didn't help some folks adjusting to Task style, and they keep using callbacks”.
Re: Everything .NET programmers know about Asynchronous Programming is wrong
#40Earlier quoted context omitted.
What's wrong with TaskCompletionSource? I use it constantly. It's great for translating other async styles (like passing a callback as the last argument) into tasks. How would you implement Observable.LastAsync, without using something equivalent to TaskCompletionSource along the way?
I think your parent is arguing that, despite TaskCompletionSource exists, some people still don't use it much and resort to callbacks (presumably because they have not learned about it). As in “adding TaskCompletionSource to the framework didn't help some folks adjusting to Task style, and they keep using callbacks”.
Ah, that makes sense.