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…
  • anlumo@feddit.de
    2·
    1 year ago

    As someone who has tried doing multithreaded design with Arc/Mutex, this is a complete nightmare. You constantly get into deadlocks and performance is abysmal, because Mutex is serializing access (so it’s not really async or multithreaded any more).

    • BB_C
      1·
      1 year ago

      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?