I have a basic technical question. I work in C for embedded systems, so I'm a bit "behind the times."
How is "await" any different from a regular blocking system call? A regular system call does exactly what is being described: The system call happens, and then when it is finished, execution resumes where it left off.
(Yes, this makes the thread block... which is why you have multiple threads. I think the answer will have something to do with this, though...)
If you remember the (gnu, ossp) pth library or any of the various cooperative multitasking equivalents for C, this is all the people raised on javascript, who started writing callback APIs for C#/ObjC discovering the same idea.
await is equivalent to "yield" or "wait" in most of those systems. The idea is to pause execution and jump back to the cooperative scheduler, which will eventually execute the function call in question. Once that call ends up with a result, the scheduler will then (eventually) resume your function with the result at the point you yielded. In the midst of all that, various other threads of control will be scheduled briefly -- for instance, the ones servicing sockets and whatnot. It's all single threaded and cooperative -- typically with an event system embedded.
Part of the callback "mess" is the result of the short memory of our industry. I was working with these kinds of systems in C code years and years ago. It didn't take long for most people to realize that you wanted to abstract the callbacks to the scheduler so you were writing your code instead fucking with the state machine mechanism used to implement the cooperative framework in question. No references to abstract CSP (or CPS :-)) ideas needed, really -- it's basic practical knowledge that seems to have been ignored over time.
I'm not a beliver, so I may be missing something important...
As far as I can see, await makes it possible to do things like:
- UI Thread starts Thread X to do something slow;
- Thread X is processing, in the meantime the user clicks on something that requires X's result;
- Only now the UI thread stops, waiting for X.
Your program stay responsive, unless it's completely not able to do so.
As I said, I still don't think it's a so important feature. It is quite rare that one needs such kind of coordination in UI programs, and there are better mechanisms for no-interactive software (that optimize for throughput, not responsiveness)... As a second thought, it may be very relevant for games, I don't know.
I also don't get why the node.js people consider it so important to have concurrence at a web server. For me, it only makes sense for sites that have less concurrent requests than server cores, AKA: nobody.
No, you got it wrong.
Await never blocks the UI thread.
Instead, the compiler rewrites your sequential code into a state machine. When you await on a task, the compiler turns this into scheduling a continuation. No blocking.
The idea is that while you're waiting on some kind of I/O or other asynchronous activity to complete, the thread you're on can do some other work. Threads are relatively heavyweight compared to the sort of cooperative multitasking that can be done through await or callbacks.
How is "await" any different from a regular blocking system call? A regular system call does exactly what is being described: The system call happens, and then when it is finished, execution resumes where it left off.
(Yes, this makes the thread block... which is why you have multiple threads. I think the answer will have something to do with this, though...)