Live data from Hacker News

Everything .NET programmers know about Asynchronous Programming is wrong

hanselminutes.com

41–50 of 57 posts

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

#41

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…

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 GetSession (provider, isLast, options, token);
        } catch (TaskCanceledException) {
            throw;
        } catch (Exception ex) {
            providerExceptions.Add (ex);
            // Fall back to next provider
        }
    }

    // Neither provider worked
    throw new AggregateException ("Could not obtain session via either provider", providerExceptions);

Or this:

    async Task GetSession (AccountProvider provider, bool isLast, LoginOptions options, CancellationToken token)
    {
        if (!SessionManager.NetworkMonitor.IsNetworkAvailable)
            throw new OfflineException ();

        var account = await GetAccount (provider, !isLast, options);
        if (account == null)
            throw new Exception ("The user chose to skip this provider.");

        var service = provider.Service;
        var session = new Session (service, account);

        if (service.SupportsVerification) {
            // For services that support verification, do it now
            try {
                await service.VerifyAsync (account, token);
            } catch (TaskCanceledException) {
                throw;
            } catch (Exception ex) {
                throw new InvalidOperationException ("Account verification failed.", ex);
            }
        }

        return session;
    }
Depending on the conditions, the method may or may not “freeze”, but the calling code doesn't care.

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

#43

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…

Just fyi, you're raising the question, not begging it.

Despite the desires of pedantic prescriptivists obsessed with maintaining the "purity" of a poor translation into English of the Latin name of a logical fallacy as the sole use of the phrase "Begs the question" in English (a use which is always intransitive), the always-transitive (and thus, impossible to confuse with the fallacy name) use of "begs the question" in a way which makes more sense with the normal English definition of the words in the phrase is in widespread use, is well-understood, and actually provides an avenue for the intransitive fallacy-naming use to make some sense (as the intransitive use can be viewed as a special case of the transitive form where the object -- the question a call for the answer is made -- is the same question that the original proposition was attempting to answer.)

So, the pedantry on this point is pointless and counterproductive.

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

#44
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…

IMHO the C# team made the right decision. What you're suggesting is a very leaking abstraction. Running stuff by default on the current thread is a sure recipe for deadlocks.

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

#45
post #17

Earlier quoted context omitted.

Please show your math. I took 80,000,000/86400 and I got 926. So you seem to be off by about 1.

I used bc. It's probably an issue of floor vs round....

$ echo "scale=7; 80000000 / (24 * 60 * 60)" | bc

925.9259259

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

#46
post #23
post #12

Earlier quoted context omitted.

I think async is a systems programming tool rather than an application programming tool. If you're writing a web server or a web browser, it'd be useful. But for a web application, you're already sitting on a highly scalable and robust async library called IIS so when you need a background task the easiest thing to do is to make it a RESTful API call. I find many web developers now intuitively break up their applicat…

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…

I was going to say the same thing. As a specific example I am currently working on a web application with multiple, complex views requiring several dropdowns. We noticed a dramatic speedup in these views when we refactored the controller to retrieve data for dropdowns using async/await.

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

#47

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…

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.

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

#48

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…

First note: Async should NOT be in the language. Support for such constructs should be in the language, and then libraries should add features such as async (like F# has done for years).

Second note: If your app has lots of short-ish lived requests, you can just achieve parallelism by having a decent-sized threadpool and just run each request on a thread. Who cares if you have 400 threads? It'll scale well enough (as you noticed).

However, if the app is doing long-running requests/clients, and you dedicate a thread to each one, then you end up with a lot of extra overhead. Using C#'s async model can simplify the code while keeping things lightweight.

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

#49

"Everything .NET programmers know about Asynchronous Programming in ASP.NET is wrong" would perhaps be a better title.

I would've gone with, "Over 14 Month Old Podcast Makes Overly Broad Claims to Linkbait" as a headline.

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

#50
post #47

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.

await will unwrap exceptions from the task object
Post reply on HN