3 ms·
`thread::scoped` attempts to use lifetimes in order to enforce that values on the parent thread's stack would live throughout the life of the child thread, such
by carllerche 12y ago
`thread::scoped` attempts to use lifetimes in order to enforce that values on the parent thread's stack would live throughout the life of the child thread, such that it would be safe to pass references to values on the parent thread to the child thread. However, the actual implementation used unsafe blocks. While this is unfortunate (thread::scoped was pretty cool), it isn't a hit against the Rust borrow checker.
- dbaupp 11y agoIt's not immediately obvious, but this isn't actually a problem with the idea of passing references to child threads. As background, `scoped` returns an RAII token and safety (references remaining valid while the child thread runs) is enforced via a destructor on that token. The issue is that reference counted types can have cycles, which are never destroyed, so placing the token in a reference counted cycle will stop the destructor running and hence risks unsafety. It's fairly non-trivial to achieve this unsafety, but even the slightest risk is not acceptable for safe functions in the standard library, so we aren't going to ship it as is. Fortunately, there are a few ways we can adjust things so that the interaction between reference counting and scoped threads doesn't cause problems, e.g. modify the reference counted types so that they cannot store types that require that the destructor be run like the `scoped` token, or guarantee safety in a way that doesn't hinge on the destructor of an object the user has ownership of.