3 ms·
How is this different from the prior 1.0 scoped threads? I remember the whole "Leakpocalypse" event that lead to the deletion of the API, (and subsequently, to
by GolDDranks 4y ago
How is this different from the prior 1.0 scoped threads? I remember the whole "Leakpocalypse" event that lead to the deletion of the API, (and subsequently, to invention of this API, where the scope guard is represented as an additional closure) but those were entirely lexical too, right? Rust borrows in general are pretty much lexical in the sense that you only analyze the body local function, nothing more. Rustc can't reason about dynamic invariants, you need runtime checks for that.
- masklinn 4y agoProbably some sort of flexibility / infectivity e.g. let’s say you have a function a which calls a function b with some borrowed data, b wants to spawn and return a thread (possibly wrapped in some other structure). In the original acception I think you could literally do that, a scoped thread would just be a normal RAII object with various lifetime bounds. With the new scoped threads, I’d think you need to create the scope in a and pass the scope handle to b so it can spawn the thread correctly.