[pavlov]

But the difference is that wait_all() is blocking the thread, right? Or does it keep running the event loop while it's waiting, so callbacks for other events can be processed on the same thread?

If it does the latter, the stack will keep growing with each nested wait call:

main -> runEventLoop -> someCallback -> wait_all -> runEventLoop -> anotherCallback -> wait_all -> ...

The async/await transformation to a state machine avoids this problem.

[flohofwoe]

Yeah it blocks the thread, any other "user work" needs to happen on a different thread. But if you just need multiple non-blocking IO operations run in parallel it's as simple as it gets.

(the operating system's thread scheduler is basically the equivalent to the JS "event loop").

[pavlov]

Desktop operating systems all have application event loops that run within a single thread because the OS thread scheduler is not the same thing. If you just want an event loop, trying to use threads instead for everything will often end up in tears due to concurrent data access issues.

[flohofwoe]

An async/await runtime doesn't necessarily need to run everything on the same thread though (that's really just a Javascript runtime restriction), instead it could use a thread pool. In this case, the same concurrent data issues would apply.

[gloryjulio]

Yes, basically golang model

[mpweiher]

Use one or more service threads to do most work off the UI thread.

[pavlov]

Yes, sure. Operating systems nowadays provide useful thread pool runtimes for this purpose, like Apple’s GCD.

In no way does it mean that you don’t need an event loop because threads exist, as was the contention here.

[mpweiher]

1. You don't need either thread pools or GCD for this. GCD generally makes things worse.

2. It absolutely does mean you don't need the main thread event loop for non UI-events.

[mrfox321]

Right, so it's less efficient than async.

Async would let you yield at the gather.

[flohofwoe]

The wait_all() "yields" to the operating system's thread scheduler, which switches to another thread that's ready to run (or if fibers are used instead of threads, a 'fiber scheduler' would switch to a different fiber within the same thread).

Taking into account that an async/await runtime also needs to switch to a different "context", the performance difference really shouldn't be all that big, especially if the task scheduler uses fibers (YMMV of course).