gh-119344: Make critical section API public #119353
Conversation
colesbury
requested review from
a team,
markshannon,
methane and
erlend-aasland
as code owners
colesbury
force-pushed
the
gh-119344-critical-section-api
branch
from
fb1579a
to
c61ba72
Compare
colesbury
requested review from
vstinner and
encukou
and removed request for
hugovk and
ezio-melotti
Include/cpython/critical_section.h
Outdated
| // Python releases without a deprecation period. | ||
| struct PyCriticalSection { | ||
| // Tagged pointer to an outer active critical section (or 0). | ||
| uintptr_t _prev; |
There was a problem hiding this comment.
Would it be possible to add "cs_" in the name? It helps refactoring and to navigate in the code.
- _prev => _cs_prev
- _mutex => _cs_mutex
Same suggestion for PyCriticalSection2.
There was a problem hiding this comment.
I've renamed the fields
| # error "this header file must not be included directly" | ||
| #endif | ||
|
|
||
| // Python critical sections |
There was a problem hiding this comment.
Maybe move this doc to Doc/c-api/init.rst, or merge it with Doc/c-api/init.rst?
There was a problem hiding this comment.
I think the file documentation is still useful even with the public Doc/c-api/init.rst docs. The file docs talk more about specific internals like PyThreadState.critical_section.
| @@ -2195,3 +2195,100 @@ The C-API provides a basic mutual exclusion lock. | |||
| issue a fatal error. | |||
|
|
|||
| .. versionadded:: 3.13 | |||
|
|
|||
| Python Critical Section API | |||
There was a problem hiding this comment.
Mabye add a label for easy referencing in the future.
There was a problem hiding this comment.
I've added a label
Co-authored-by: Petr Viktorin <encukou@gmail.com> Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com> Co-authored-by: Victor Stinner <vstinner@python.org>
|
@Yhg1s - this PR makes the critical section API public. Is it acceptable to include this in 3.13? There's a bunch of refactoring to make the API public, but no new functionality. |
|
Yes, this can go into 3.13 if it gets into beta 3. (How many more APIs do you think we'll need for 3.13? :P) |
|
This is the last one, I promise! |
|
Thanks @colesbury for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13. |
|
Sorry, @colesbury, I could not cleanly backport this to |
…9353) This makes the following macros public as part of the non-limited C-API for locking a single object or two objects at once. * `Py_BEGIN_CRITICAL_SECTION(op)` / `Py_END_CRITICAL_SECTION()` * `Py_BEGIN_CRITICAL_SECTION2(a, b)` / `Py_END_CRITICAL_SECTION2()` The supporting functions and structs used by the macros are also exposed for cases where C macros are not available. (cherry picked from commit 8f17d69) Co-authored-by: Sam Gross <colesbury@gmail.com>
|
GH-120856 is a backport of this pull request to the 3.13 branch. |
This makes the following macros public as part of the non-limited C-API for locking a single object or two objects at once. * `Py_BEGIN_CRITICAL_SECTION(op)` / `Py_END_CRITICAL_SECTION()` * `Py_BEGIN_CRITICAL_SECTION2(a, b)` / `Py_END_CRITICAL_SECTION2()` The supporting functions and structs used by the macros are also exposed for cases where C macros are not available. (cherry picked from commit 8f17d69)
This makes the following macros public as part of the non-limited C-API for locking a single object or two objects at once. * `Py_BEGIN_CRITICAL_SECTION(op)` / `Py_END_CRITICAL_SECTION()` * `Py_BEGIN_CRITICAL_SECTION2(a, b)` / `Py_END_CRITICAL_SECTION2()` The supporting functions and structs used by the macros are also exposed for cases where C macros are not available.
This makes the following macros public as part of the non-limited C-API for locking a single object or two objects at once. * `Py_BEGIN_CRITICAL_SECTION(op)` / `Py_END_CRITICAL_SECTION()` * `Py_BEGIN_CRITICAL_SECTION2(a, b)` / `Py_END_CRITICAL_SECTION2()` The supporting functions and structs used by the macros are also exposed for cases where C macros are not available.
This makes the following macros public as part of the non-limited C-API for locking a single object or two objects at once. * `Py_BEGIN_CRITICAL_SECTION(op)` / `Py_END_CRITICAL_SECTION()` * `Py_BEGIN_CRITICAL_SECTION2(a, b)` / `Py_END_CRITICAL_SECTION2()` The supporting functions and structs used by the macros are also exposed for cases where C macros are not available.
This makes the following macros public as part of the non-limited C-API for locking a single object or two objects at once.
Py_BEGIN_CRITICAL_SECTION(op)/Py_END_CRITICAL_SECTION()Py_BEGIN_CRITICAL_SECTION2(a, b)/Py_END_CRITICAL_SECTION2()The following supporting functions and types are also public for use by bindings from other languages:
PyAPI_FUNC(void) PyCriticalSection_Begin(PyCriticalSection *c, PyObject *op)PyAPI_FUNC(void) PyCriticalSection_End(PyCriticalSection *c)PyAPI_FUNC(void) PyCriticalSection_Begin2(PyCriticalSection2 *c, PyObject *a, PyObject *b)PyAPI_FUNC(void) PyCriticalSection_End2(PyCriticalSection2 *c)PyCriticalSection(struct contents private)PyCriticalSection2(struct contents private)Note that the more esoteric APIs are still internal-only as part of
pycore_critical_section.h.Py_BEGIN_CRITICAL_SECTION()andPy_END_CRITICAL_SECTION()public in the non-limited C API #119344See also C-API WG Issue:
Docs: