Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything .NET programmers know about Asynchronous Programming is wrong

hanselminutes.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#51

Post by sequence7 »

earlz wrote: post #37

The 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 t…

So why don't you just define a non async method (A) and then one that is async (B) that calls A? If you want to run async then call B if not then call A.

If you could define a method as async and then call it either syncronously or not the whole point of the async keyword is lost. You would end up with the compiler doing a load of work because every developer will just slap async on every method just in case rather than actually thinking about what needs to be async and what doesn't.

Adding the async keyword is not a magic bullet, there's a huge amount of work going on under the hood every time you use it and it's important that developers appreciate that.

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#52

Post by earlz »

sequence7 wrote: post #51
earlz wrote: post #37

The 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 t…

So why don't you just define a non async method (A) and then one that is async (B) that calls A? If you want to run async then call B if not then call A. If you could define a method as async and then call it either syncronously or not the whole point of the async keyword is lost. You would end up with the compiler doing a load of work because every developer will just slap async on every method just in case rather t…

The problem with your two-method suggestion is that it's usually not /me/ I'm concerned about. The problem is usually things like "I need to open this file from a synchronous context in a Windows Store App". The problem is that with Windows Store (where async is suppose to shine), async is the rule, not the exception

Also, two methods sharing the same code sounds absolutely horrible.

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#53

Post by sequence7 »

earlz wrote: post #52
sequence7 wrote: post #51

Earlier quoted context omitted.

So why don't you just define a non async method (A) and then one that is async (B) that calls A? If you want to run async then call B if not then call A. If you could define a method as async and then call it either syncronously or not the whole point of the async keyword is lost. You would end up with the compiler doing a load of work because every developer will just slap async on every method just in case rather t…

The problem with your two-method suggestion is that it's usually not /me/ I'm concerned about. The problem is usually things like "I need to open this file from a synchronous context in a Windows Store App". The problem is that with Windows Store (where async is suppose to shine), async is the rule, not the exception Also, two methods sharing the same code sounds absolutely horrible.

Method B calls A it doesn't share any code and it is then explicit that one method is async and the other is not. You want to do two different things so why not have two methods?

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#54

Post by mcgwiz »

harrytuttle wrote: post #2

Genuine 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…

Heuristically, anytime you're doing I/O (network or filesystem) could be an opportunity to increase concurrency with async/await. By using asynchrnous I/O and trickling that asynchronocity all the way up to ASP.NET, you make much more efficient use of the ThreadPool and allow more requests to be served. That's because you are recouping cycles otherwise lost on blocking.

This isn't the only way to increase concurrency. Obviously you can grow your IIS web farm as well. But async/await (or some other .NET asynchronous programming pattern[1]) is a one-time .NET development cost as opposed to a recurring infrastructure/hosting cost.

[1] http://msdn.microsoft.com/en-us/library/jj152938.aspx

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#55

Post by thomasz »

TeddyLondon wrote: post #28
harrytuttle wrote: post #16

Earlier quoted context omitted.

The problem is that it's pretty useless in non-systems programming language.

It is pretty useful for ui stuff, you can start a wait cursor in a button event, do what you need to then put the cursor back when your done, all in one thread without having to use background threads or anything. It is pretty simple for that scenario and avoids the cross thread marshalling you need to do in win forms.

Don't forget the SOA scenario: One service calls 0..n others to fulfill a request. Each of those calls is IO bound.

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#56

Post by danabramov »

cmircea wrote: post #50
mfn wrote: post #47

Earlier quoted context omitted.

In your first code sample, I'm pretty sure you don't need the return await GetSession (provider, isLast, options, token); Unless there's more to the method, just remove the async modifier and directly return the task returned by GetSession.

await will unwrap exceptions from the task object

Exactly, and thus I'll be able to try next provider in the loop.

Re: Everything .NET programmers know about Asynchronous Programming is wrong

#57

Post by danabramov »

mfn wrote: post #47
danabramov wrote: post #41

Earlier quoted context omitted.

In some scenarios it simplifies the code greatly. It may or may not be applicable to your app. Just a few weeks ago I was able to convert a nightmare-ish recursive asynchronous method to a `foreach` loop with `await`s inside. It's cool when you can do this: var providerExceptions = new List (); // Try each provider in turn foreach (var pi in providers) { token.ThrowIfCancellationRequested (); try { return await GetSe…

In your first code sample, I'm pretty sure you don't need the return await GetSession (provider, isLast, options, token); Unless there's more to the method, just remove the async modifier and directly return the task returned by GetSession.

If I did that, the code would always return at the first GetSession call.

Instead, it unwraps exceptions, and while it propagates cancelations, it ignores other exceptions and tries other providers in turn.

In fact, I could even use `break` or `continue` in the midst of async code, and there would be no problem.

Also I just love using `try` and `finally` in async code—with callbacks, you have to do finalization from all error and success paths (which can be a lot of places).

Post reply on HN