DOC: Document that GIL must be grabbed (and Py_IsInitialized()) #140
Conversation
I honestly don't remember if that ``Py_IsInitialized`` wasn't just to tape over C++ related deficiencies, but I suspect there isn't much to be avoided there... (I.e. if we take care of the GIL for the other library, we also have to do this check for them which would normally be their job.) Closes dmlcgh-103
Co-authored-by: Antoine Pitrou <pitrou@free.fr>
Our experience in PyArrow (not in DLPack context) is that it's required for robust integration with C++: |
|
Yeah, makes sense: If you knew it came from Python, it would be your job to store it in a way like that |
Co-authored-by: Antoine Pitrou <pitrou@free.fr>
docs/source/python_spec.rst
Outdated
| @@ -134,6 +134,37 @@ C API which is called either when the refcount on the capsule named | |||
| Note: the capsule names ``"dltensor"`` and ``"used_dltensor"`` must be | |||
| statically allocated. | |||
|
|
|||
| The ``DLManagedTensor`` deleter must ensure that sharing beyond Python | |||
| boundaries is possible, this means that the GIL must be acquired explicitly. | |||
There was a problem hiding this comment.
aquired explicitly if the original memory comes from python runtime and deleter involves interacting with python runtime. If the original memory allocation comes from other languages(e.g. c++ and exposed to python) and de-allocation does not involve python runtime, then it is not necessary to grab the GIL.
There was a problem hiding this comment.
Fair, added "[...] if it uses Python objects or API"
I honestly don't remember if that
Py_IsInitializedwasn't just to tape over C++ related deficiencies, but I suspect there isn't much to be avoided there...(I.e. if we take care of the GIL for the other library, we also have to do this check for them which would normally be their job.)
Closes gh-103