4 ms·
Awesome update! It's good to see scoped threads here. Btw, can someone explain how these are safe when the initial implementation wasn't? The problem was that s
by Lvl999Noob 4y ago
Awesome update! It's good to see scoped threads here. Btw, can someone explain how these are safe when the initial implementation wasn't? The problem was that someone could put a reference to a local variable inside an `Rc` or `Arc` and leak it with reference cycles, right? How is that case prevented now?
- kam 4y ago`std::thread::scope` takes a closure, and joins the threads after the call to the closure returns, rather than relying on `Drop`.
- game-of-throws 4y agoSide note: since memory leaks were deemed safe, there are easier ways to deliberately leak than using reference cycles. The most straightforward are `mem::forget` and `Box::leak`.
- duckerude 4y agoThe original implementation gave out a handle that waited for all the threads to end when it was dropped (i.e. went out of scope). That would prevent premature cleanup. But it was possible to leak the handle so that it would never be dropped even at the end of the block, and then it wouldn't wait for the threads. The new implementation calls a closure and waits for the threads when that closure returns. Unlike the destructor here's no way to stop that code from running when it should.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]