junrushao1994 commented on a change in pull request #14733: Enable zero-copy
from numpy to MXNet NDArray
URL: https://github.com/apache/incubator-mxnet/pull/14733#discussion_r279128406
##########
File path: include/mxnet/c_api.h
##########
@@ -823,6 +823,23 @@ MXNET_DLL int MXNDArrayToDLPack(NDArrayHandle handle,
*/
MXNET_DLL int MXNDArrayFromDLPack(DLManagedTensorHandle dlpack,
NDArrayHandle *out_handle);
+
+/*!
+* \brief Create a NDArray backed by a dlpack tensor.
+*
+* This allows us to create a NDArray using the memory
+* allocated by an external deep learning framework
+* that is DLPack compatible.
+*
+* The memory is retained until the NDArray went out of scope.
+*
+* \param dlpack the pointer of the input DLManagedTensor
+* \param out_handle pointer holder to get pointer of NDArray
+* \return 0 when success, -1 when failure happens
+*/
+MXNET_DLL int MXNDArrayFromDLManagedTensor(DLManagedTensorHandle dlpack,
Review comment:
The most important reason that I didn't call the original API is its
overly-strong underlying assumption made me scared. Correct me if I was wrong,
but I feel that it asks the DLManagedTensor to be alive throughout the entire
lifetime of the internal NDArray, i.e. the frontend should never delete the
numpy ndarray before we delete the mx's one, otherwise the entire process would
crash on the destructor. To be more specific, in the implementation of
`NDArray::FromDLPack`, the deleter would assume the argument `tensor` always
points to a valid address - this doesn't usually hold, especially for that in
the frontend user may delete the numpy's ndarray. I was not aware why it is
initially designed like this.
----------------------------------------------------------------
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:
[email protected]
With regards,
Apache Git Services
