You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Much of our IPC code presumes the use of the encapsulated message format. At some point we should ensure that we can address reconstruction of record batches when the "RecordBatch" Flatbuffer metadata was constructed more generally to reference buffers that may be located in different locations of a memory map or some other virtual address space
Antoine Pitrou / @pitrou:
What is the usefulness of this compared to the C data interface? Passing memory pointers in Flatbuffers wouldn't let you handle buffer lifetime, at least (unless you pass a release callback somewhere on the side).
Wes McKinney / @wesm:
I removed it from the 1.0.0 milestone. I agree that the C interface is a better solution for in-memory handoffs.
One meaningful deficiency with the C++ IPC implementation is the 0 frame of reference (relative to the start of the encapsulated message body). So it's only usable in the context of encapsulated messages. I'll rewrite the JIRA a bit to reflect this issue (which is non-urgent, but may be interesting to do something about someday)
Much of our IPC code presumes the use of the encapsulated message format. At some point we should ensure that we can address reconstruction of record batches when the "RecordBatch" Flatbuffer metadata was constructed more generally to reference buffers that may be located in different locations of a memory map or some other virtual address space
Reporter: Wes McKinney / @wesm
Note: This issue was originally created as ARROW-6783. Please see the migration documentation for further details.
The text was updated successfully, but these errors were encountered: