4 ms·

Definitely! Vale, Lobster, and Cone all require explicit annotations for anything that could cross thread boundaries. Vale's design bends the rules a little bi

Definitely! Vale, Lobster, and Cone all require explicit annotations for anything that could cross thread boundaries. Vale's design bends the rules a little bit, it blends structured concurrency with region borrow checking to allow things to temporarily escape the current thread. [0] I believe Lobster spawns a new VM per thread, and has some special abilities to share data between them, but I'm vague on the details. Cone requires an explicit permission to allow crossing thread boundaries, which I think will work pretty well. [1] I've read about biased RC before, but have been skeptical because of the branching involved. How has it worked out in practice? [0] https://verdagon.dev/blog/seamless-fearless-structured-concurrency https://verdagon.dev/blog/seamless-fearless-structured-concu... [1] https://cone.jondgoodwin.com/safety.html https://cone.jondgoodwin.com/safety.html

nu11ptr 4y ago
I've just read about it, never actually used it verbatim tbh, but just found it kinda fascinating. I wrote a somewhat modified version (I don't track local thread ID, I use Rust's type system and Send/Sync properties instead) of the algorithm for a very different purpose: I use it to allow safe moves back and forth between (non-atomic) Rc and (atomic) Arc objects. For this purpose, it is very useful. The actual Rc/Arc operations are no more expensive than regular Rust Rc/Arc (except for the last decrement on Rc - slightly more expensive) I got the idea from this person (I didn't use their algorithm though - they probably do it similar to how I do it though): https://crates.io/crates/hybrid-rc https://crates.io/crates/hybrid-rc
rfoo 4y ago
Biased GC is implemented the "nogil" Python fork. It worked okay-ish.