jorgecarleitao commented on pull request #8287: URL: https://github.com/apache/arrow/pull/8287#issuecomment-700159555
> As a general design suggestion, on the C++ side we have separate structs (classes) for the import (consumer) side and the export (producer) side. Just 2 cents, though. Can you explain the rational for the two structs? Is it due to different ownership rules? The design so far (for consumption) in this PR: * Have two structs (`FFI_ArrowArray` and `FFI_ArrowSchema`) that have ABI compatibility with `ArrowArray` and `ArrowSchema` struct in the C data interface. * Have one struct that owns both `FFI_ArrowSchema` and `FFI_ArrowArray`, that knows how to convert from and to Rust's implementation of an Arrow Array. I am still a bit lost as to who owns what: when we pass the pointer from C to Rust, does C assume that it should not free the resources if it goes out of scope? I.e. what is the contract between the consumer and the producer with respect to whom should free memory (rust's by calling the "free")? Or is the contract: both check for pointer nullability of the `release` and call it accordingly. If so, what about threat safety? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
