Recently, I found myself returning to a compelling series of blog posts titled
Zero-cost futures in Rust
by Aaron Turon about what would become the foundation of Rust's async ecosyste…
As someone who has tried doing multithreaded design with Arc/Mutex, this is a complete nightmare.
I myself often use channels. And pass owned data around.
I don’t think anyone argues that Arc+interior-mutation is ideal. But it’s the over-the-top language like “complete nightmare” that some may take issue with.
Note that I again make the distinction between Mutex, and all interior mutation primitives. Because Mutex is indeed a bad choice
in many cases. and over-usage of it may indeed be a signal that we have a developer who’s not comfortable with Rust’s ownership/borrowing semantics.
You constantly get into deadlocks and performance is abysmal, because Mutex is serializing access (so it’s not really async or multithreaded any more).
Same note about Mutex specifically as above.
Avoiding deadlocks can definitely be a challenge, true. But I wouldn’t say it’s often an insurmountable one.
What crate did you use for interior mutability, async-lock, tokio, parking_lot, or just std?
I myself often use channels. And pass owned data around.
I don’t think anyone argues that Arc+interior-mutation is ideal. But it’s the over-the-top language like “complete nightmare” that some may take issue with.
Note that I again make the distinction between
Mutex, and all interior mutation primitives. BecauseMutexis indeed a bad choice in many cases. and over-usage of it may indeed be a signal that we have a developer who’s not comfortable with Rust’s ownership/borrowing semantics.Mutexspecifically as above.async-lock,tokio,parking_lot, or juststd?I used parking_lot back then.