File tree Expand file tree Collapse file tree 2 files changed +36
-0
lines changed
Expand file tree Collapse file tree 2 files changed +36
-0
lines changed Original file line number Diff line number Diff line change @@ -64,5 +64,6 @@ Table of Contents
6464 python_ir
6565 runtime
6666 opaque_pyobject
67+ resource
6768 links
6869 misc
Original file line number Diff line number Diff line change 1+ +++++++++++++++++++++++++++++++++++++++++
2+ Implicit and explicit resource management
3+ +++++++++++++++++++++++++++++++++++++++++
4+
5+ Pointer API
6+ ===========
7+
8+ The Python C API has multiple APIs which implicit resource managements:
9+
10+ * ``PyBytes_AsString() ``
11+ * ``PyUnicode_AsUTF8AndSize() ``
12+
13+ These functions return a pointer to data. The pointer becomes a dangling
14+ pointer once the object is deleted.
15+
16+ This API makes the assumption that the memory address of Python objects are
17+ fixed. Python implementations moving objects in memory have to pin these
18+ objects in memory to implement the API, and pinning memory is inefficient in
19+ this case.
20+
21+ The ``Py_buffer `` API has a ``PyBuffer_Release() `` function which can execute
22+ code when a buffer is no longer needed:
23+
24+ * Call ``Py_DECREF(obj) ``
25+ * Free memory if the buffer was a memory copy
26+ * Close files
27+ * etc.
28+
29+ Array of objects
30+ ================
31+
32+ ``array = &PyTuple_GET_ITEM(tuple, 0) `` is a common code pattern to access a
33+ Python tuple as a C array of ``PyObject* ``: array of ``PyObject** `` type. It
34+ makes the assumption that a tuple stores ``PyObject* `` and ``PyObject** ``
35+ becomes a dangling pointer once the tuple is destroyed.
You can’t perform that action at this time.
0 commit comments