✳flâneur — a map of the web's best reading

Why choose async/await over threads? | Hacker News

news.ycombinator.com · 47,196 words · saved by 1 readers

Multi-threaded async/await gets ugly. If you have serious compute-bound sections, the model tends to break down, because you're effectively blocking a thread that you share with others. Compute-bound multi-threaded does not work as well in Rust as it should. Problems include: - Futex congestion collapse. This tends to be a problem with some storage allocators. Many threads are hitting the same locks. In particular, growing a buffer can get very expensive in allocators where the recopying takes place with the entire storage allocator locked. I've mentioned before that Wine's library allocator, in a .DLL that's emulating a Microsoft library, is badly prone to this problem. Performance drops by two orders of magnitude with all the CPU time going into spinlocks. Microsoft's own implementation does not have this problem. - Starvation of unfair mutexes. Both the standard Mutex and crossbeam-channel channels are unfair. If you have multiple threads locking a resource, doing something, unlocki

Why choose async/await over threads? | Hacker News Hacker News new | past | comments | ask | show | jobs | submit login Why choose async/await over threads? ( notgull.net ) 430 points by thunderbong on March 25, 2024 | hide | past | favorite | 458 comments Animats on March 25, 2024 | next [–] Async/await with one thread is simple and well-understood. That's the Javascript model. Threads let you get all those CPUs working on the problem, and Rust helps you manage the locking. Plus, you can have threads at different priorities, which may be necessary if you're compute-bound. Multi

Explore this link on the map →

related reading