3 ms·
I'm a fan of Rust (although I haven't waded into it much yet), and a heavy user of C, and the one particular thing I find missing so far is a properly Rust-ifie
by ff317 7y ago
I'm a fan of Rust (although I haven't waded into it much yet), and a heavy user of C, and the one particular thing I find missing so far is a properly Rust-ified abstraction of QSBR-style RCU, with the full power and flexibility that can be achieved with liburcu-qsbr in C.
For C it's just some header files and a library and you get some amazing performance magic out of it. It's the key missing feature that makes me leery of going down the road of converting some existing C daemon code over to Rust.
It's hard to do low-level QSBR as a primitive for scalable threading in languages other than C/C++ unless you bake the abstraction in pretty deeply. I think it's probably possibly to bring it to Rust in a meaningful way, but probably non-trivial to integrate with all the other cool things going on in the language for concurrency and the borrow-checker, etc.
- steveklabnik 7y agoI’m not super familiar, but from a cursory google, it looks like crossbeam is the rust equivalent?
- tene 7y agoI'm not familiar with the implementation details of QSBR, and I've never used liburcu-qsbr, but what I've read about it tonight sounds a lot like the im[0] crate in terms of behaviour. The behaviour in im is a data structure where readers get a reference that pins data in memory, so they have a consistent snapshot to read from. Any mutations made while there are outstanding read references will write to a new allocation for the part that changed, so the two references can share most of the data through structural sharing. When there are no outstanding read references, mutations happen in-place. Have I correctly understood QSBR if I think it's similar behaviour to this? How does the implementation differ? [0] https://docs.rs/im/13.0.0/im/ https://docs.rs/im/13.0.0/im/