Back to Basics: Efficient Async and Await - Filip Ekberg - NDC Porto 2022
Vložit
- čas přidán 7. 07. 2022
- We've all experienced deadlocks, and we all hate them, but how do we prevent (and potentially fix) them?
That's right, no one likes applications crashing or giving users an unexpected behavior.
Introducing asynchronous patterns is so much more than just applying async and await to your methods; you really, I mean really, need to understand what's going on.
In this session, we'll make sure you know how to avoid crashing your applications, and how to adhere to best practices when applying asynchronous patterns in our .NET applications.
Check out more of our featured speakers and talks at
www.ndcconferences.com
ndcporto.com - Věda a technologie
Great talk, nice walkthough of async/await. I was kind of disappointed by the lack of mention of ConfigureAwait - it's extremely important, especially in older dotnets, and can be very useful in WPF :)
50:08 Task.WhenAll(t1, t2) is not the same as await t1; await t2; in my opinion
Great talk!
I've been using async/await for a few years now without really understanding it, until now.
Thank you Filip!
Thanks for uploading these! This definitely taught me knew things about async/await!
30:48 "not only did it change what this method returns..."
indeed! The compiler _completely replaces the method body with a state machine handler_
the method becomes an incomprehensible mess of classes, secondary state machines and methods
edit: ah, you demonstrate it, nice
Just point that the official MS documentation says: `async void` should only be used for event handlers.
async void is the only way to allow asynchronous event handlers to work because events do not have return types (thus cannot make use of Task and Task). Any other use of async void does not follow the TAP model and can be challenging to use, such as:
- Exceptions thrown in an async void method can't be caught outside of that method.
- async void methods are difficult to test.
- async void methods can cause bad side effects if the caller isn't expecting them to be async.
Fantastic talk, thank you!
I would also add that is good practise to provide cancellation token to every function if it's support
e.g. 57:43 line 40 or in Task.Delay from 54:34
because most of libraries implement it in correct way, so e.g. we would not wait for full line when reading file or wait whole time when we use delays
Great talk!
Learn how to use async all the way properly and the cancelation token.
Nice talk! learned a couple of new things
Conclusion: Exit from power point is harder than writing Task Parallel Library (56:29).
47:21
if you encourage people to stop using await when no need to get the result you should mention about cons of this approach
20:30 "contextual keyword" does not mean "they do a lot of compiler magic to solve the same problems that we could do without async and await...".
"contextual keyword" means the compiler recognises it as a keyword if encountered when expected but it is not a _reserved_ word.
This means you _can_ use any of where, set, get, async, await, or, and, not as identifiers, verbatim, while you can not use the word _if_ as an identifier: at best, you can use @if
Jesus Christ :o
Why doesn't an async function automatically return a Task without having to annotate it like that?
Oh desktop? Oh... (closes the video)
oooooh boy
here we go
Nothing new 🙁 just repeated information that was already available everywhere several years ago