Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Cleanup unused cffi handles to free memory #4135
Previously, the set of CFFI handles in the
To allow CFFI handles to be collected,
It's unavoidable that multiple CFFI handles will exist per underlying object, because we don't want to hash all Values to dedupe them (we only hash objects that we are forced to due to lifting to a Key). Because of this, doing reference counting on the rust side (although easy enough) would have been confusing due to both reference counting and multiple copies existing.
Memory previously leaked in
(TODO: benchmarks to follow)
I have a general question.
Value is always created on Python side and then got passed to Rust code as return value of extern functions, right? So now since you removed Copy trait from Value struct, does that mean now when you assign (bind) the return value to a variable, the ownership is transferred as the consequence of the assignment? And previously, the struct was just copied field by field?
(assume above is correct) And with ownership of the object moved to rust code, the object will be cleaned (which means drop is also called) once the object is out of scope, even if there is still handle on the Python side?
@JieGhost: No: rust has move semantics by default, so the vast majority of the time, the value (and its ownership) were moved from one owner to another. Copy is used implicitly in positions where the borrow checker determines that two paths will end up using the same struct. A lot of the changes (like the one you pointed out above) were positions where we were implicitly (maybe even unnecessarily) copying this data. But I think it was still fine to have marked Value
EDIT: I think you were right, in that variable references are always copies in rust... the