async/await helps with that, but like with any other abstraction, if you use it without understanding how it works and what it actually does, it’s bound to come back and bite you at some point.

How exactly?

The use case for perf improvement with async/await is for IO based issues, eg instead of burning a thread waiting for IO to complete, use IO completiion ports (on winders) blah blah.

If your work is CPU bound you can't async/await it away magically.

Maybe I'm misunderstanding you?

Yea I’m also confused. You’re main thread should be able to run completely asynchronously from worker threads. With async, you are constantly hitting a memory barrier while the worker thread completes the promise and then the main thread draws the result. Ideally, the worker thread should be able to natively queue its task for non-blocking repaints.

Side note, this is why I’m a huge fan of Qt. They really did a fantastic job on building that framework for c++ to make it more safe

async/await is about non-blocking, not IO specifically. You can use async to not block the current thread while IO completes, or use it not block while while some CPU work completes (in this case on another thread while the UI is unblocked).

It's similar to using an event loop architecture for all UI actions.

I was specifically referring to input handling off the main thread, from GP’s original complaint. IO only.