News for hackers. Stuff that matters.

A comment on How to think about `async`/`await` in Rust. Parent comment

Re:How to think about `async`/`await` in Rust by pavlov on Wednesday July 05, 2023 @12:30PM (#36602790)
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.
[ Parent | on HN ]
Re:How to think about `async`/`await` in Rust by flohofwoe on Wednesday July 05, 2023 @01:49PM (#36604164)
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.
[ Parent | on HN ]
Re:How to think about `async`/`await` in Rust by gloryjulio on Wednesday July 05, 2023 @02:50PM (#36605254)
Yes, basically golang model
[ Parent | on HN ]
Re:How to think about `async`/`await` in Rust by mpweiher on Wednesday July 05, 2023 @02:28PM (#36604877)
Use one or more service threads to do most work off the UI thread.
[ Parent | on HN ]
Re:How to think about `async`/`await` in Rust by pavlov on Wednesday July 05, 2023 @03:07PM (#36605508)
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.

[ Parent | on HN ]
Re:How to think about `async`/`await` in Rust by mpweiher on Friday July 07, 2023 @06:33AM (#36629710)
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.

[ Parent | on HN ]