zeroshade commented on code in PR #36489:
URL: https://github.com/apache/arrow/pull/36489#discussion_r1261393596
##########
cpp/src/arrow/c/bridge.h:
##########
@@ -166,6 +166,140 @@ Result<std::shared_ptr<RecordBatch>>
ImportRecordBatch(struct ArrowArray* array,
/// @}
+/// \defgroup c-data-device-interface Functions for working with the C data
device
+/// interface.
+///
+/// @{
+
+/// \brief EXPERIMENTAL: Type for freeing a sync event
+///
+/// If synchronization is necessary for accessing the data on a device,
+/// a pointer to an event needs to be passed when exporting the device
+/// array. It's the responsibility of the release function for the array
+/// to release the event.
+using ReleaseEventFunc = void (*)(void*);
+
+/// \brief EXPERIMENTAL: Export C++ Array as an ArrowDeviceArray.
+///
+/// The resulting ArrowDeviceArray struct keeps the array data and buffers
alive
+/// until its release callback is called by the consumer. All buffers in
+/// the provided array MUST have the same device_type, otherwise an error
+/// will be returned.
+///
+/// If a non-null sync_event is provided, then the sync_release func must also
be
+/// non-null. If the sync_event is null, then the sync_release parameter is
not called.
+///
+/// \param[in] array Array object to export
+/// \param[in] sync_event A pointer to an event-like object if necessary for
+/// synchronization, otherwise null.
+/// \param[in] sync_release Function pointer to release the sync event
+/// \param[out] out C struct to export the array to
+/// \param[out] out_schema optional C struct to export the array type to
+ARROW_EXPORT
+Status ExportDeviceArray(const Array& array, void* sync_event,
+ ReleaseEventFunc sync_release, struct
ArrowDeviceArray* out,
Review Comment:
So the event is related to the stream and whatever would be pushing the data
through the device, rather than being related to the buffers objects
themselves. So the user would need to know how to produce the right sync event
(and therefore the correct release) for whatever the underlying device they are
using is. In theory we could instead just template this on the event type
rather than accepting the void* directly (but then we would just be
`reinterpret_cast`ing it to a `void*` anyway.
The alternative (or potential evolution of this) would be to encapsulate
this like your suggestion https://github.com/apache/arrow/issues/36103 but it
would still be up to the user to have created the event and pass it through
since the user would need to properly call the method to add triggering the
event as a task on the stream for after the data is populated. But we'd still
need the user to pass it in.
I was putting off the creation of that event/stream encapsulation as an
evolution of this in a subsequent PR but I can do that with this PR if you
think that's better.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
