Await Async Tasks Are Getting Awesome in .NET 9!
2024 ж. 8 Сәу.
80 852 Рет қаралды
Until the 21st of April, buy ANY Dometrain course and get the From Zero to Hero - LINQ in .NET course for free!! dometrain.com/courses/
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video I will introduce you to a brand new await async and Task feature coming in .NET 9!
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet
Lovely feature BTW that zoomed middle region messes with my brain
OMG!!! I've been waiting for this feature for years!
You could've just used System.Linq.Async. This functionality has already existed for years
For concurrent processing, there's also the channels library that's been available since .net core 3.1 and the excellent channels.extensions library that makes it so much easier. I'd love to see a video on this.
Great video as always. One bit of feedback, please provide a link to referenced blog posts, especially when they're so old. Thanks!
The new feature looks good. There is an old way to achieve the same: var tasks = Enumerable.Range(1, 5).Select(Calculate).Select(async i => Console.WriteLine(await i)); await Task.WhenAll(tasks); Here you reuse the defer idea of the LINQ
Been waiting for this for so long. Totally perplexed as to why it has taken so long for something so fundamental.
What happens when an exception is thrown by one (or more) of the tasks?
I think an AggregateException would be thrown.
My guess is an exception will be thrown when you `await` an individual task, and regarding the entire `await foreach` block, my guess would be: same behavior as `await`ing a `Task.WhenAll()`
I would expect that you get the exception when awaiting, or check and don't await if the task is faulted
Exception won't be thrown until you await the task. So it would not be thrown by Task.WhenEach.
Well, that's what people will explore for themselves.
Best segue into a course advertisement ever! So smart, so smooth... I applaud you.
That is beautiful, thank you!
Late happy birthday Nick! keep up with the great work
It's great to see an continuous investment in all areas of the framework. Would like to see more focus on reactive extensions (RX) though, especially around async APIs.
There is a going effort to improve RX
So simple and clean, great!
The video is very weirdly zoomed in some areas
It's because the author is naked. He says it briefly right at the beginning of the video.
@@urzalukaskubicek9690 what the fuck are you saying
@@urzalukaskubicek9690😂😂😂
@@urzalukaskubicek9690that's crazy
@@urzalukaskubicek9690Yes, he certainly does!
Wow that was way nicer than I expected
Great feature, thanks for explanation.
We are performing many of those independent tasks. Up until now, we have been using queues to solve the problem.
Thank you Nick for sharing this great feature. I have implemented my own as many of us for a batch System IO operation. I was checking in a While loop with task has completed, cancelled or hasException properties. Then removing from batch operation array and adding new one to task array. I don't know why Microsoft wait for this feature so far.
This is a nice addition to the task echo system for sure!
I hope to see some F# content on Dometrain one day. Love to learn how to leverage the language to write apis.
As an option we can use a some kind of the Pub/Sub approach to subscribe to the results as they appear
That looks neat!
Hey Nick love this!! Can you post the link to the Stephen Toub article?
devblogs.microsoft.com/pfxteam/processing-tasks-as-they-complete/
Couple questions 1. When using WhenEach what thread does the Consle.WriteLine execute on? 2. Is any overhead introduced by using await task vs task.Result, given the fact that we know task.Status == RanToCompletion? Or maybe we don't know that, depends on how errors are handled. 3. Any difference in performance using WhenEach over await Task.WhenAll(tasks.Select(t => t.ContinueWith(async x => Console.WriteLine(await x)))); or is it just cleaner to look at?
seconding question 3, I'd assume since nick didn't mention it that ContinueWith in general won't give the same intended behavior but I want to actually know.
I've been using the exact approach you showed with WhenAny for quite a while. It's good there's an easier way, and more performant way to do it though.
this is a really cool feature, that i didn't realize i needed
Very very nice feature. Has anyone benchmarked how much more efficient it is in comparison to the old approach?
I achieved similar functionality using ActionBlocks from the TPL. I can see the benefits of this approach and how concise it is, but I think the functionality available in the TPL is under utilised when it comes to async processing.
I would love to see a video of you looking at the implementation by microsoft and explaining why it is better :) Great vid as always Nick
I'm trying to think of where I would use this... In examples like this, I would usually write a method or a class that orchestrates the order of events. The signature would return a task that encapsulates the order of events. I don't doubt this has valid use cases, I'm just curious to see how people plan on using it and if there's something I'm missing.
That's great if the T in Task[] are all the same. but if I'm calling multiple APIs using implicit parallelism, for example, and they all return a different types, then it doesn't really help me
You could work around that by using Task. Then you could pattern match to figure out what model was returned.
@@warrenbuckley3267 Yeah that's an idea. 👍
@@warrenbuckley3267 very costly
This is awesome!
Why not appending a .ContinueWith() and then do the WhenAll() ? would the end result be the same?
Thank god we have Stephen. Btw I think the following PLINQ does the same: await ParralelEnumerable.Range(1, 5) .ForAll(I => Comsole.WriteLine(Calculate(I)))
I think the difference is that WhenEach will give you back the Task itself, not just the result so you have more flexibility on how you handle failure
@@nickchapsas I can't think of a use case where you want to continue the method without awaiting all tasks... additionally are 2 ways to do the thing you're describing already. 1. Creating a method that consumes the original method's value and add there the custom logic. 2. Use continuations. Here is a small program to demonstrate the second case: foreach (var t in Enumerable.Range(1, 6) .Select(async n => { await Task.Delay(new Random().Next(0, 10)); return n; }) .Select(t => t.ContinueWith(v => Console.WriteLine(v.Result)) .ToArray()) await t;
@@user-dc9zo7ek5j Absolutely agree! I've never heard about the problem which Nick described, as it is easily handled by continuations.
Not exactly the same under the hood. I guess "parallel" is named because it "must" be paralleled. With it, you want to request some OS threads to work on your tasks, not "limited" in only the running thread concurrency realm.
Generally if I have a set of tasks I need chained, I'll wrap the call chain into another async method. So the caller really just needs to wait till everything is done.
Wow, finally!
I assume "await task" throws just for the specific task on exception, so we can nicely process errors of each task. I like it.
that's really good indeed.
@3:43 "ton" although spelled with an "o" is actually pronounced "tun" (rhymes with "fun").
Why would you use a list instead of array in this sample?
Because of Remove()
To expand on the other reply, it only works because it removes items from the list and you cannot remove items from an array. You would have to splice/copy the items to a new array. List works similarly behind the scenes but Microsoft is much better at optimization than you or I.
Does WhenEach run in parallel? hard to tell the difference to the serial syntax foreach task in listOfTasks { await task }
Great!🎉❤
Very very cool! 🥳
"A sink a wait". I've seen it.
I figured it would be solved by IAsyncEnumerable as that makes the most sense. Finally :)
Great video
Awesome!
Very very elegant.
Is there a possibility to limit number of concurrent tasks it can await at once? Because if the input list is 1000 tasks long, spinning them all together will just create a bunch of overhead.
Probably use a SemaphoreSlin
Wake me up when they make EF Core async friendly. That would make a huge difference.
Very nice
This nice one
Finally! :)
Why did'nt you mention System.Linq.Async?
why do you have to do the await on the foreach and then on the task? It seems like the task is being called two times.
Been using Stephen Toub's Interleaved method for the longest time. Nice to finally see this as a Task extension method.
I do not see WhenEach() available in my .NET 9 Preview version. Getting Compiler Error CS0117 Task' does not contain a definition for 'WhenEach' My version is 9.0.100-preview.2.24157.14 Ideas?
Same, I don’t even see it in the dotnet 9 preview on GitHub
Wild effect in this video
Ok what version of .NET 9 preview is this working. There is no "WhenEach" method
good question
Looks cool, but couldn't you just move the "Calculate()" call to an async method which awaits and does the post-processing and then finally Task.WhenAll on those? I rarely have a List of tasks that I don't control the creation of.
Wait so what's the difference between `Task.WhenEach()` and `tasks.ToAsyncEnumerable()`?
WhenEach() is in BCL whereas ToAsyncEnumerable() is an reactive extension from System.Linq.Async
@@nanvlad But other than that, no difference?
@@RealCheesyBread BCL should be more reliable and performant. Also it can be improved by Microsoft on the very low level.
“Hello everybody my name is marioooo” sorry this was in my head when i heard the intro 😭😭😭😂
Why not just use channels with separate sessions if you need resource syncing over single groups of tasks in a short process?
Because it would be overkill
This is nice
I feel like a simple solution to do this before .net 9 would have been to just wrap the task with another task that handles the result, and then awaitall those tasks instead.
Indeed. I fail to see the excitement here, it's a trivial thing to solve
@@simonwood2448 This is syntactic sugar that is easier to use and reduces boilerplate. It’s certainly better. Im just saying I feel the original problem itself wasn’t some impossibly hard thing.
That's not the same, though. That will process the results concurrently, while the new method processes sequentially.
@@protox4 In the new method the tasks are still running concurrently, but the loop is responding to when each one completes. So this should, in theory, work the same way: await Task.WhenAll( tasks.Select(async t => { Console.WriteLine(await t); }));
@@TazG2000 that's still concurrent, because they are not sequentially writing to the console. each task writes as soon as it is finished, but they could be finished at the same time. you could probably make all tasks write sequentially with some kind of mutex like SemaphoreSlim, but that gets uglier
Its taken so long as this was non issue, can be done in multiple ways. Normally u would limit the Tasks logical threads for example with max degree of parallel cuz u dont want to run more than that, so a new task wont start until there is place for another anyway and when that happens the ended task can report. This function is just a cherry on the ice cake.
🤔 interesting!
Ive written that while loop before. Feels bad / looks ugly, but what are you going to do. I'm still enjoying great new things in .NET8, I dont need to be excited for 9 yet!
I just realized we're as far from 2012 as 2012 was from 2000
Hi nick i need you help😢, i had some problem with parallel and async , i had 1000 batch data but need make it faster, i use parallel but got error in database why i cant crud if i use parallel , iam using sqlserver . If you read this maybe you can help me iam stuck 😢😢
Nice feature. But I will actually have to wait for a next LTS version of .NET (likely 10) to use it in the real life.
nick i am a huge fan of the dometrain courses, but I would prefer, that the presenters should make prepared slides rather then drawing while talking, it slows things down and i prefer when they talk FAST. deep dive C# is GGOOOOODDDDD
Yeah, this feature was long overdue.
Last time I had this problem, I just went with firing an event after task is done
Not completely happy about the need to await the task inside the Task.WhenEach loop. If the WhenEach is supposed to yield a completed task why not access the result immediately in the loop, why the need to await the task "again"? EDIT: Is it because the tasks can return different types of results?
You need it for error handling. This pattern lets you await a task in a try/catch, deal with any exceptions, and then continue iterating.
@scottbaldwin2477 Exactly, the place where the await is, there will happen the possible throws. Writing the entire thing myself while watching this video made that clear for me already. You can put a try block inside your await foreach block to handle each individual failed task. Which is the problem that you cannot with Task.WaitAll for example, which completely stops everything on the first exception.
@@scottbaldwin2477 ah, of course. Makes sense.
@@scottbaldwin2477 Right, makes sense.
I don't see any use-case for that feature. Just use a queue und do a while with await for each loop... you can even do a concurrent queue and do a parallel foreach... but still, what is the use-case for this? Process N-Items with the same type, waiting for each type until it its finished... thats like normal basic programming, not using any tasks at all... the point of tasks is do stuff in parallel - using the actual cores of a CPU, which people tend to forget that there is actual hardware running that code. Even in cases, where i do heavy data transformations and require multiple steps, even then i would not do it this way... maybe scrapping a website, parsing links... to prevent API blocking, due to too many request, would be the only use-case i could think of... Even multiple IO-access can still be done in parallel...
5:40 Why "tasks.Any()" instead of "tasks.Count > 0"?
Any seems a semantically easier to read. It is English not math. Plus no hard coded number. Technically slower, but modern computers can do billions to trillions of flops and the vast majority of all use cases will be bottlenecked by unmanaged resources like IO and network.
@@zpa89 Are we after performance or more readable code? Gotta pick one.
@@keyser456 you are neglecting that modern dotnet puts some SERIOUS effort into optimizing linq expressions. In fact, I would bet the compiler optimizes away the more basic extensions entirely when the underlying runtime type is known.
@@zpa89 I'm neglecting nothing. There's an unhealthy obsession for "clean code", and it's to the point where people (by your own admission) are willing to trade off some performance. Will a tiny perf tradeoff be the deathblow in an app? Probably not. Is .Any() really that much better than Count > 0 from a readability standpoint? Definitely not. We're programming, not writing a book for kids.
@@keyser456 we are all humans. We are writing code that humans must maintain. As humans, we speak in human languages. Writing code in a more naturally human way makes code easier to read. When a human wants to decide whether they have to deal with something, they ask "are there any x left?" They don't say "is the count of x greater than zero?" Beyond that, the vast majority of software engineers are dealing with IO/network bound work. CPU cycles you save by hyper optimizing your code pale in comparison to the time you must spend waiting for unmanaged requests to return. I would love to say that one day you will learn all of this but I have interviewed hundreds of engineers from all over the world, I lead a team of 60+, and unfortunately it seems that tenure just does not make you a more intelligent engineer. If you aren't one of the bright ones now, you may never be.
If you want to process tasks as they happen, you're two steps away from the point when it's serious enough to use System.Threading.Tasks.Dataflow
It seems odd that it returns an async enumerable of tasks, and not the results. I’m sure there’s a good reason for that but.. yeah.. odd.
Well, I think the easiest way would be to get a list of tasks which includes processing. Like `Enumerable.Range(1, 5).Select(async order => Console.WriteLine(await Calculate(order)))`. Clearly you can replace `Console.WriteLine` by anything else. I think it is much cleaner and easy to grasp.
It's not quite the same, though. That will process concurrently, while the new method processes sequentially.
@@protox4 right, that requirement wasn't stated explicitly
@@MrBurikellathat is literally the entire point of the video....
Or you could just have a function that does the Calculate(i) AND console.writeline ... WhenAll - that still does what it is suppose to do - waits for all of them.
This was my thought. It's what I would do in this situation.
What is an actual use for this?
The only feature I've been waiting years for is to safely run these await async methods from a sync method. Damn mess Microsoft created.
this just like select in golang
Looks useful. Though I'm a bit torn about the ever increasing number of syntactic special cases in C#. The for, foreach, and now await foreach loops often take the place of higher-order functions, but proper higher-order functions are a bit crippled in their own special way. Doesn't this feel a bit like these projects where people only ever add features, but never refactor? A new programmer these days seems to be learning more and more cryptic rules for each real concept behind them.
To be fair, "await foreach" (IAsyncEnumerable) was added in 2019 in C# 8.
C# has always supported backwards compatibility when possible.
thought this was a video about async2
He did a separate video about that. And that's just an experiment currently, not officially in 9.
If people just used async methods and, what is even more important, would use CancellationToken so that api calls could actually be cancelled!
Maybe I'm just an old gezzer, but... if you want something done as they finish, why not pass them a callback? Yes, i know, context is gone, but if that is so paramount, is it not more of a "code smell" than anything else?
Callback hell, from nesting too many call backs is inevitable the moment a project becomes even the slight bit complex I'd assume. Being able to write I/O and other async tasks in a synchronous way just makes larger code bases more understandable for larger teams, or even yourself in the future
You could've already done that by calling Task.ContinueWith(...) on all of the tasks in the list, if you want to deal with it and the problems that arise. C# was one of the first languages to use async await so it makes sense that the standard library is going to use it where it can. After all, "Callbacks are the goto statement of our generation"
@@milkandhenny How does nesting come into play? Something like OrderComplete(int order){...} being passed to something like Task ProcessOrder(int order,Action callback) was all they needed to finish their work, no nesting here, it's fully local. By the time WhenAll() resolves, you know they all went through OrderComplete() and move on. Think you're conflating "work completion callback" with "forward return point callback". The first finishes work, but the calling site is still waiting. The second IS the "forward return" point because the calling site IS NOT waiting.
@@ErazerPT As long as none of your calls have dependencies, callbacks aren't terrible. As soon as you start having to coordinate them, callbacks are terrible.
@@adambickford8720 Once more, those are NOT the kind we are talking about. And yes, you're 100% right but Task's don't magically free you from it. If you're accessing shared resources, you'll still need some sort of await semaphore. Concurrency IS hell.
Am I missing something? tasksWithContinuation = taskList.Select(t => t.ContinueWith(delegate)).ToList();
You are passing a delegate, won't resolve in the main thread, I think that is the difference
@@ricardoduarte442 if there's such a requirement then the needed behavior can be configured in the ContinueWith method.
That will process the results concurrently, while WhenEach processes sequentially.
@@protox4 Oh yeah true LOL
It will be interesting to know what happens in race condition, if two tasks getting completed at same time, will this handle out of box or something that needs a special handling
Since the order is not guaranteed I don't think it's an issue at all
Similar to JavaScript
This is great! But before instead of playing around with a list I would most probably just create a new method that would invoke both the original task and do the result processing and just run this one with Task.WhenAll. The list approach feels very engineery.
Something is wrong with your video as we can't see all the information. Seems like the encoding had some corrupted data.
What about the library System.Threading.Tasks.Dataflow?
You said "no lists involved" when there is obviously a list involved. I understand enough that it could be any sort of IAsyncEnumerable but your code sample still used a list.
I think is more about the allocation, is like using IEnumerable with ApplicationDbContext from EF, you are only bringing items to memory when u need them, in this case u are just getting the task pointers, not a list that have tasks (I AM NOT 100% SURE ON THIS, actually would like to see a response from Nick on this)
Still feels hacky when used to go or rust channels
c# has channels as well, not sure why he didn't talk about it since they're much more useful in most cases
What is the difference between this and Parallel.ForEachAsync?
Why dont just use callbacks? Seems like a problem out of nowhere
Well Nick, after buying 12 of your courses you could have given me that one for free... :/
Email me
Huh, so many TaskHelper.WhenAll will be retired soon..
Linq.Async definitely looks better than this