I hope the author at some point adds the section on ConfigureAwait. I've seen code bases where the devs have added .ConfigureAwait(false) to all invokations "just to make sure".
That's what you're meant to do!
Asynchronous Programming in C#
61–70 of 186 posts
Re: Asynchronous Programming in C#
#62Why do we need the `async` keyword? What is the difference between a function which returns a Task , and an async function which returns a Task ?
An non-async Task is returning a Task object, where the return statement of an async Task method is of type int (which will be wrapped in the resulting Task). ”return 1;” eg only works in the latter case.
Re: Asynchronous Programming in C#
#63I would call myself an extremely experienced and knowledgable C# programmer with 10+ years of experience and even I found a few things surprising or new in this guide. I think C# async/await implementation is the biggest con on the .NET community, because it gets constantly hailed as one of the easiest ways of async programming but this guide itself proves to me that there are so many gotchas which are not obvious at…
The way I put it: .NET async makes the easy things easier and the hard things harder.
The problem is that Task/Task was the foundation for async, and it's a bad foundation. Even with the ability to write your own duck-typed awaiters (and the advent of ValueTask), the widespread use of Task means if you're writing async code you're going to have a tough time getting away from it.
Re: Asynchronous Programming in C#
#64>Prefer async/await over directly returning Task This one seems questionable to me. I've never been bitten by any of the cons mentioned[1], and it's even noted that doing it this way does incur performance costs. I've learned over the years that if the code path is very prolific, it pays to avoid the async state machine. I'm curious if others could expand on this one. [1] https://github.com/davidfowl/AspNetCoreDiagno…
Always using async/await is recommended to avoid _surprising_ behavior. If a method with a signature Task Foo(); and it is not declared with async and it throws an exception, the exception is propagated directly to the call site. Think of this usage: var getBarTask = Foo(); // do some other stuff try { var bar = await getBarTask; } catch (Exception ex) { handle exceptions } Then if the Foo is not async the exception…
This surprised me. When they wrote LINQ and iterables, MS went to great lengths to ensure exceptions that could be thrown immediately (before iterating) were. I wonder why async/await are the opposite.
Re: Asynchronous Programming in C#
#65Earlier quoted context omitted.
.NET Core and later has ValueTask for that usecase.
Around 50% of my work .NET coding and I find It's becoming really hard to keep up with this. .NET more and more feels to me like the typical MS approach where they just keep cranking out new stuff without cleaning up existing stuff. Some of the new things are very good, some are half baked, and it's difficult to figure out on what side these new features are. Just lately I did some Entity Framework coding and noticed…
The problem is that .NET has been taken over by web developers, and they expect the kind of breakneck pace of change and half-baked tools that the Javascript ecosystem has become accustomed to.
Re: Asynchronous Programming in C#
#66>Prefer async/await over directly returning Task This one seems questionable to me. I've never been bitten by any of the cons mentioned[1], and it's even noted that doing it this way does incur performance costs. I've learned over the years that if the code path is very prolific, it pays to avoid the async state machine. I'm curious if others could expand on this one. [1] https://github.com/davidfowl/AspNetCoreDiagno…
Unless you're doing awaits in a tight loop of thousands/millions of calls, the overhead of the state machine is almost non-existent, which leads to the next question, what are you doing that requires await in a tight loop of that many calls? The whole point of await is to use it to yield a thread while waiting on a long running operation, if your await returns nearly instantly then use the synchronous version and avoid the overhead.
Re: Asynchronous Programming in C#
#67I have been a C# developer for a while as well now and I'm not sure if this is true: "Use of async void in ASP.NET Core applications is ALWAYS bad. " Depending on the context, it can even be recommended to do async void. See Stephen Cleary's brilliant explanation of this: https://blog.stephencleary.com/2012/02/async-and-await.html Edit: The correct link is this, see first table column exceptions: https://docs.microso…
An exception in an async void function will crash your entire ASP.NET Core application. There is no reason at all to use these in ASP.NET Core, always use Task or ValueTask as the return type of your async functions.
There are still event handlers.
You just have to always remember to always wrap async void methods with try { ... } catch (Exception ex){ ...}
Re: Asynchronous Programming in C#
#68Earlier quoted context omitted.
Concurrency does not require multi-threading. Maybe you mean parallelism? Concurrency can still be really valuable in the context of a single threaded application.
If a program wants to perform a task in an async way without delegating it to an external program (like a database server or the OS' I/O system), it has to use threads, right? I think the point is that concurrency, for some tasks, basically requires multithreading. Not for the parallelism benefits, but just to be able to make concurrency possible for a task that requires blocking a thread.
Concurrency is more about having order independent units of computation. You can concurrently run operations on a single thread, although there is less benefit if no IO is involved. It's not something you'd likely do in practice unless there was IO.
Re: Asynchronous Programming in C#
#69This is a great overview
Re: Asynchronous Programming in C#
#70I would call myself an extremely experienced and knowledgable C# programmer with 10+ years of experience and even I found a few things surprising or new in this guide. I think C# async/await implementation is the biggest con on the .NET community, because it gets constantly hailed as one of the easiest ways of async programming but this guide itself proves to me that there are so many gotchas which are not obvious at…
Ex-.NET guy here, can confirm. Coming from JVM-land I was constantly told that async await is something that makes C#/.NET much better than Java. I personally could not understand why. Async await is not as easy as it looks, and most .NET programmers who I knew, would just hammer at things to make it work. "Hey, this is an HTTPClient call? Put an await in front of it?" "Oh, is the IDE showing an error? Try .Configure…
async/await is so much wildly better than previous version of .NET async programming.
If you've ever had to deal with the IAsyncResult pattern in older .NET code, you'll never complain about await.
https://docs.microsoft.com/en-us/dotnet/standard/asynchronou...