-
Notifications
You must be signed in to change notification settings - Fork 847
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
Remove Clone and copy source structs internally #1449
Merged
Merged
Changes from all commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
fa2ec44
Remove Clone and copy source structs internally
viirya 44bafd3
Remove drop_in_place and add more comment
viirya 0705d33
Add export_into_raw
viirya 27c075d
Fix format
viirya 29157db
Fix clippy
viirya ac804bc
Move to export_array_into_raw
viirya 3fc6fab
Fix clippy
viirya 888cbe0
Fix doc
viirya 6007aed
Use write_unaligned
viirya File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually after thinking more on this, it seems this won't address the original problem neither. It basically just calls
drop
onFFI_ArrowArray
(which is empty), but doesn't free the memory pointed byarray
andschema
.For instance, if
array
andschema
are fromArc::into_raw
, then the memory allocated for theArc
will become dangling after this, and thus memory leak.I'm thinking whether we'll need two APIs, one where we are able to take the ownership of the memory allocated for the
array
andschema
(e.g., exported byArc::into_raw
from Rust itself), and one where we cannot take the ownership (e.g., memory was allocated by other languages such as Java), and thus requires the exporter to free the memory by itself later.For the latter, we can clone the content for
FFI_ArrowArray
andFFI_ArrowSchema
, and set the content of the originalarray
andschema
to beFFI_ArrowArray::empty()
andFFI_ArrowSchema::empty()
so that the exporter can just safely free the memory later.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently if user try to export using into_raw and and don't import using from_raw (we can assume it's a normal case? as they export data to be used by others they don't need to import again), they might have memory leak.
After check the CPP-import implementation, I think this change is fine. We even can remove the two drop_in_place call as it seems unnecessary.
What we need is to redesign the ArrowArray::into_raw(), we can't use Arc::into_raw in the implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea the
drop_in_place
here seems unnecessary.I'm not sure if it's possible to redesign
ArrowArray::into_raw
though, since after exporting the array, we need to free up the memory allocated forFFI_ArrowArray
. However this can only be done after the exported array is imported viaFFI_ArrowArray::try_from_raw
, which we don't know when.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is correct that with one single API, we cannot deal with both cases: raw pointers from Arc and not from Arc.
I'm not sure two separate APIs is good. With a single API, we can ask users to take care of releasing the raw pointers (either Arc or not) by themselves.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If Rust side is importer, we already have it as we can do it now by creating empty structs, passing raw pointers to exporter.
If Java side is importer, we may need an export API which takes raw pointers from Java and replaces its content.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, agreed. Do you plan to add the export API in this PR, or separately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be straightforward to add, let me add it here. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a new API
export_into_raw
. Please check it. Thanks.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm trying to catch up with these discussions since I'll soon have a need to create Buffers from foreign memory. The cast to
*mut
followed bystd::ptr::replace
here doesn't look safe to me. When the pointer is coming from anArc
that seems to violate rust's unique ownership rules.