Re:How to think about `async`/`await` in Rust
by starcraft2wol on Wednesday July 05, 2023 @12:47PM
(#36603076)
> in GUI programming where you simply can't have blocking code a lot of the time,
This can be transparently solved by the GUI library. The main thread does a loop and polls events from a queue. Those events are generated by a gui on another thread. It can be designed so gui itself can be manipulated on the mainpulated on the main thread, and the event handling and rendering is double buffered, or synchronized for you.
> easier to reason about
The style of code OP is describing looks like `if then else`. You can reason about the state of the system using traditional programming logic.
Re:How to think about `async`/`await` in Rust
by jayd16 on Wednesday July 05, 2023 @02:29PM
(#36604887)
What GUI system are you referring to? As far as I know, pretty much all major UI frameworks use a single thread, or at best a gui thread and a render thread.
Re:How to think about `async`/`await` in Rust
by starcraft2wol on Thursday July 06, 2023 @10:46PM
(#36626439)
I believe SDL works how I described. But yes, I was trying to describe a gui/render thread split.
I find it rather odd that you say "easier to reason about.". I find it much harder to keep a mental model in my head which thread currently does what compared to async/await code which you can write like synchronous code. You generally don't have to be that hyper-aware.