21–30 of 186 posts
"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.microsoft.com/en-us/archive/msdn-magazine/2013/...
We use async/await pretty much universally throughout our codebase today. One thing to keep in mind is that this mode of programming is actually not the most performant way to handle many problems. It is simply the most expedient way to manage I/O and spread trivial things across many cores in large, complex codebases. You can typically retrofit an existing code pile to be async-capable without a whole lot of sufferi…
I 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…
I don't see this reflected in the linked article at all. Aren't you confusing async void with async Task?
>We were able to share this experience with .NET in time for C#’s await to ship. Sadly, by then, .NET’s Task had already been made a class. Since .NET requires async method return types to be Tasks, they cannot be zero-allocation unless you go out of your way to use clumsy patterns like caching singleton Task objects.
I 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…
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/AspNetCoreDiagnosticScenarios/b...
http://joeduffyblog.com/2015/11/19/asynchronous-everything/ >We were able to share this experience with .NET in time for C#’s await to ship. Sadly, by then, .NET’s Task had already been made a class. Since .NET requires async method return types to be Tasks, they cannot be zero-allocation unless you go out of your way to use clumsy patterns like caching singleton Task objects.
Otherwise, as others have commented, I despise how async/await is "95% done". The remaining 5% will come to bite haunt you and the documentation is less than satisfiyng. E.g., how does TaskScheduler interact with async? Nowhere documented, except answered on StackOverflow by Stephen Cleary that "it should work".
I prefer Java's CompletableFuture and Executors. It's more verbose, but at least there's no hidden magic. From the documentation you can infer exactly how it'll behave.
http://joeduffyblog.com/2015/11/19/asynchronous-everything/ >We were able to share this experience with .NET in time for C#’s await to ship. Sadly, by then, .NET’s Task had already been made a class. Since .NET requires async method return types to be Tasks, they cannot be zero-allocation unless you go out of your way to use clumsy patterns like caching singleton Task objects.
.NET Core and later has ValueTask for that usecase.
Earlier quoted context omitted.
Strong agree. I've seen devs with 20 years of experience on me write silly inefficient code because they're lulled into a false sense of security by the marketing of async/await. Multithreading is one of the hardest problems in software, and Microsoft decided that the best way to solve it is to get smart and experienced people to stop forget everything they know and instead learn a bunch of opaque apis that interact…
async/await is not about multithreading at all though...
The canonical Microsoft tutorial on async spends about half its time talking about hiw to make your code concurrent to take advantage of async.
https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...