How to think about `async`/`await` in Rust

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

Re:How to think about `async`/`await` in Rust by jayd16 on Friday July 07, 2023 @12:15AM (#36627020)

Pulling out the render thread just helps offloads the GPU calls, no? The GUI thread still has the usual single thread concurrency issues most programmers deal with.

[ Parent | on HN ]