-12
Unsafe Rust: living up to its name (lemmy.sdf.org)
submitted 10 months ago by to c/programmer_humor@programming.dev
11 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 6 points 10 months ago (2 children)

Note how the ticket cited is in an unsafe block, because it uses the OS scheduler, not its own. It is not Rust's fault.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 10 months ago

    Rust doesn't have a scheduler.
    The issue is the false assumption, that the remove operation can safely be done without taking a lock. This can be done in some specific data structures using atomic operations, but here the solution was to just take the lock. The same thing could have happened in a C code base but without the unsafe block indicating where to look for the bug.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 10 months ago

    Yeah, I'm not saying it's rust's fault. Restricting this to unsafe makes it a lot easier to reason about where such problems can occur.

    I just don't think anyone should give the impression that rust's memory safety is not about race conditions.

  • permalink
  • fedilink
  • source
  • parent