4 ms·
Qdrant is a async Rust project, so there will be lots of Arc. Rust safety guarantees doesn't really let share references across threads haphazardly.
by nemothekid 3y ago
Qdrant is a async Rust project, so there will be lots of Arc. Rust safety guarantees doesn't really let share references across threads haphazardly.
- menaerus 3y agoSomething being async doesn't imply shared-ptr design. But perhaps this is what Rust makes you to to achieve its safety guarantees?
- nemothekid 3y agoYes; in many cases, if there are two tasks that hold some piece of data, the compiler cannot, at compile time, when to free that data, as it doesn't know which of the two tasks will finish first. That means the lifetime of that object must be tracked at runtime, with a garbage collector. This is where you get Arc (or shared-ptr). I'm not sure how you would safely solve this in C++, but FWIW, scylladb is a high performance database that also makes use of shared_ptr.
- menaerus 3y agoMulti-threaded and/or async code can perfectly exist without shared-ptrs. And no, you don't need a shared-ptr to manage the lifetime of an object shared by two threads.
- nemothekid 3y agoThat might be true of C++, but I don't think its true in Rust. Furthermore, I don't think the performance concern is as dire as you believe - both Scylla and Redpanda, two high performance C++ databases both use shared_ptr with their async framework Seastar.
- menaerus 3y ago> That might be true of C++, but I don't think its true in Rust And which was exactly my point. > both Scylla and Redpanda, two high performance C++ databases both use shared_ptr Such argument doesn't make sense since you will find usage of shared-ptrs in probably more or less every high performance C++ codebase out there. The secrete sauce is to know _where_ and _when_ to use it. I'm not against it but I'm definitely not in favor of language forcing me to user it when I don't need it.