3 ms·
To be clear, the basic concept of scoped threads is fine, and this unsoundness was a result of explicitly `unsafe` code. The specific API chosen, however, used
by aturon 12y ago
To be clear, the basic concept of scoped threads is fine, and this unsoundness was a result of explicitly `unsafe` code.
The specific API chosen, however, used RAII guards to "guarantee" that the parent thread joined on the child thread within a certain scope. Unfortunately, it's possible to subvert the RAII guard by placing it within a ref-counted cycle, which results in its destructor never being run.
For the moment, the API is being moved back to "unstable" status.
We are considering a variety of ways to address the problem, including:
* Avoiding RAII guards in the API, instead using explicit closures to guarantee that the threads join.
* Introducing a way of marking types as "unsafe to leak", thereby allowing us to continue using the RAII-style API, but preventing use of the guard within reference counted pointers (which can leak).
- anon4 12y agoI'm wondering -- would it be possible to have a cycle checker which would be run on function exit on the objects, for which the compiler can't prove, that they don't contain cyclic references?
- steveklabnik 12y agoIn theory, things like this are possible. In practice, that's effectively a garbage collector, and current Rust is trying to take no-GC as far as possible.
- Jweb_Guru 12y agoRunning cycle collection on function exit would make Rust tremendously slow. It's possible, but not a viable solution.