4 ms·

What do you mean by `racy`?

• spoiler 6y ago
  They probably meant it is a race, not racy. Although, it's not a race I think? The method will attempt to reserve, or return Err, just like malloc would (it's not can_reserve)
  • iudqnolq 6y ago
    I think they're referring to something like this let v = vec![0; 42]; v.try_reserve(1); frob(&mut v); // I expect this not to expand the array v.push(1); // fails, because frob took the space Note that this requires passing a mutable reference to frob. Absent an explicit contract in the api documentation I wouldn't expect a function that takes a mutable reference to a vec not to mutate it arbitrarily. One option for avoiding this would be to pass a mutable reference to a slice, which allows frob to mutate elements of the vec without allowing it to push. frob(&v[..]) It can't be a race in the traditional sense, as the borrow checker will enforce only one person being able to write at a time.
    • Ericson2314 6y ago
      Yes exactly. Thanks.
• coryrc 6y ago
  Causing (or allowing) race conditions
• Ericson2314 6y ago
  OK sorry that was a mistake. It's not a race. But it's still non-local. one has to manually account for what allocation will be done, and keep the reservation in sync across refactors. This isn't a race but still scares me. Someone could write shared_v.lock().try_reserved(); shared_v.lock().something(); which would be a race. That is not `try_reserved`'s fault, and a rather easy-to-spot example, but I wonder if there are variations on this which are easier to miss.