8000 Doc: C API: Move `tp_dealloc` paragraph to `tp_dealloc` section by rhansen · Pull Request #125737 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

Doc: C API: Move tp_dealloc paragraph to tp_dealloc section #125737

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 21, 2024
Merged

Doc: C API: Move tp_dealloc paragraph to tp_dealloc section #125737

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
8000
Diff view
24 changes: 13 additions & 11 deletions Doc/c-api/typeobj.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -682,6 +682,19 @@ and :c:data:`PyType_Type` effectively act as defaults.)
Py_DECREF(tp);
}

.. warning::

In a garbage collected Python, :c:member:`!tp_dealloc` may be called from
any Python thread, not just the thread which created the object (if the
object becomes part of a refcount cycle, that cycle might be collected by
a garbage collection on any thread). This is not a problem for Python
API calls, since the thread on which :c:member:`!tp_dealloc` is called
will own the Global Interpreter Lock (GIL). However, if the object being
destroyed in turn destroys objects from some other C or C++ library, care
should be taken to ensure that destroying those objects on the thread
which called :c:member:`!tp_dealloc` will not violate any assumptions of
the library.


**Inheritance:**

Expand Down Expand Up @@ -2109,17 +2122,6 @@ and :c:data:`PyType_Type` effectively act as defaults.)
PyErr_Restore(error_type, error_value, error_traceback);
}

Also, note that, in a garbage collected Python,
:c:member:`~PyTypeObject.tp_dealloc` may be called from
any Python thread, not just the thread which created the object (if the object
becomes part of a refcount cycle, that cycle might be collected by a garbage
collection on any thread). This is not a problem for Python API calls, since
the thread on which tp_dealloc is called will own the Global Interpreter Lock
(GIL). However, if the object being destroyed in turn destroys objects from some
other C or C++ library, care should be taken to ensure that destroying those
objects on the thread which called tp_dealloc will not violate any assumptions
of the library.

**Inheritance:**

This field is inherited by subtypes.
Expand Down
Loading
0