Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FFI transfer ownership instead of cloning #2325

Closed
mversic opened this issue Jun 6, 2022 · 2 comments
Closed

FFI transfer ownership instead of cloning #2325

mversic opened this issue Jun 6, 2022 · 2 comments
Labels
iroha2-dev The re-implementation of a BFT hyperledger in RUST Optimization Something isn't working as well as it should

Comments

@mversic
Copy link
Contributor

mversic commented Jun 6, 2022

Inside ffi/derive/src/arg.rs when receiving input parameters to functions, every opaque structure is cloned so as not to deal with ownership transfer. In FFI calls best practice dictates that memory should be deallocated on the side of the FFI that allocated it. Cloning doesn't seem optimal and, if possible, some form of ownership transfer should replace it

@mversic mversic added iroha2-dev The re-implementation of a BFT hyperledger in RUST Optimization Something isn't working as well as it should labels Jun 6, 2022
@mversic
Copy link
Contributor Author

mversic commented Jun 8, 2022

Considering that opaque pointers are always allocated on the Rust side of the FFI their ownership can be sent back over and deallocated. But care must be taken to not transfer ownership of other structs

@mversic
Copy link
Contributor Author

mversic commented Jul 5, 2022

Ownership of opaque structs will be shared across FFI boundary after #2314 is merged

@mversic mversic closed this as completed Jul 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
iroha2-dev The re-implementation of a BFT hyperledger in RUST Optimization Something isn't working as well as it should
Projects
None yet
Development

No branches or pull requests

1 participant