Back to Basics: Efficient Async and Await - Filip Ekberg

[@donfoumare]

Even the sound is async in this one..

[@AngelDMunoz]

Ahh I love this talk! I learned about async stuff with promises years ago, when javascript got async/await support I kind of saw the same/similar pitfalls there too. with promises was just about returning your promises, but with async/await was not apparent that it could fail even easier than promises. I love the prevent unnecessary state machines, that is also overlooked by many Cheers! Just loved it!

[@dexterman6361]

Task.Run() creates a new thread to run stuff, but the async and await keywords don't. As the docs puts it, "The async and await keywords don't cause additional threads to be created. Async methods don't require multithreading because an async method doesn't run on its own thread". So at 25:55 "back to the caller thread" shouldn't make sense because the method never left the caller thread right! Anything I'm missing here?

[@MrDimension0]

You are right, because the default sychronizationcontext auf wpf/winforms applications queues continuations to the dispatch thread, which does execute event handler

[@dexterman6361]

@@MrDimension0 Thanks for the clarification! I was trying to understand how Async and Await works and this point confused me! Also, if you don't mind clarifying a doubt, in an application that is forced to run on a single thread (say), any async methods and the usual code (that called these async methods) has to be in some sort of loop right, suspending whatever is currently running and resuming the async methods (effectively meaning the async methods and the main method are running in some sort of time div-multiplexing)?

[@MrDimension0]

@@dexterman6361 this blog post written by the guy who implemented many parts of the async stuff, basically answers your question. It also describes how u can build that "message pump" behaviour and use it in applications that have a different model by default (like console applications) devblogs.microsoft.com/pfxteam/await-synchronizationcontext-and-console-apps/

[@dexterman6361]

@@MrDimension0 By "basically answers your question", did you mean to say my initial thought was correct? Or did you mean the link would clarify it? Thank you very much for the reference! It's a bit advanced for where I'm right now in my learning; bookmarked for future reference!

[@MrDimension0]

@@dexterman6361 u are almost completely right. There is no thread suspending involved. That's the main advantage of the async pattern, the thread is never suspended and can always pick up tasks as they occur. In consequence u got a very response application. Ofc inside the gui framework there is a dedicated thread that is looping and waiting for events being queued. When an event occurs, say a click event, the thread will consume the event out of the queue and run the specific eventhandlers. It will execute your code inside that handler until the handler task yields, because u reaching for some bytes of the wire. Your remaining code of your handler will be queued as a continuation and the gui thread continues to loop and handles further events, redraws the windows and so on. When the io task is completed the gui thread will at some point dequeue and execute your continuation. You can think of anything after an await point as a callback that is holded back somewhere in order to be continued at a later stage. When and how ithis s happening depends on the current sychronizationcontext. For gui applications it works roughly like I explained. This is more a mental model than a detailed and 100% accurate technical explanation.

[@AShahabov]

In 12:00 speaker said "Task.Run() starts asynchronous operation" and I once again confused about asynchronous's terms. Am I right in saying, that Task.Run() starts asynchronous operation mean Task.Run() starts a bunch of code asynchronously, a bunch of code has been asynchronously started is mean a bunch of code is performed in another thread without blocks caller thread?

[@eddypartey1075]

as microsoft learn says: "The core of async programming is the Task and Task objects, which model asynchronous operations. They are supported by the async and await keywords"

[@PavanKumar-xp9sb]

Github link..??

[@mehdi-vl5nn]

if you are using an async task on another thread thats multithreading:| i even don't know how the concept fits any more !

[@gunnar560]

Source Code???

[@richardbradley3684]

Anyone know why the crash at 47:17?

[@FilipEkberg]

The try/catch caught the wrong exception in the Click event handler.

[@banksy215]

To be honest this introduced more confusion than it explained.

[@GeorgeTsiros]

i have a suspicion that the "a" in await means "async" and that "await" is supposed to mean "ASYNCHRONOUS wait" and not just the verb "await".

[@milanstevic8424]

it's just a handy linguistic convenience really. it doesn't actually mean asynchronous wait, await is different from wait insofar that it implicitly expects a finite interval of time, or that something will arrive or happen soon enough. awaiting is thus synonymous with expecting something. waiting is not, it's merely doing nothing for an undisclosed amount of time, without any guarantee that it's a finite interval. however, the fact it has the same amount of letters, and that both words start with an 'a' gives off a useful mnemonic to categorize these keywords as belonging to each other. there is nothing wrong in your belief, but it might just be an excessive superstition.

[@jamesevans2507]

@@milanstevic8424 insofar lmfao. you're not writing a book on philosophy jfl.

[@levinjaytagapan4213]

Very informative

[@stevewalsh80]

Disappointing video. There is no magic in async/await when explained clearly and the confusion between parallelism and asynchronicity in this talk is not helpful...

[@seancpp]

From what I understand, parallel generally refers to multiple operations running at the same time, whether on separate threads or otherwise. Synchronous or Asynchronous refers to the control flow of the written code. Async/await doesn't affect the run-time, but rather changes the order which code executes, to allow typical blocking operations to become non-blocking. Like he explained in the video, the state machine exists on the calling thread. You can "wait" for a parallel operation to complete on your calling thread by messing with the synchronization of your code execution, rather than blocking until the data comes in. This has very obvious benefits for UI code So in my opinion, the synchronization of async/await refers to the order of execution in your code, and parallelism refers to the run-time behavior of spawning separate threads or whatever, to allow multiple tasks to run together at the same time. Correct me if I'm wrong