Skip to content
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.

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

C API: Remove PyEval_AcquireLock() and PyEval_InitThreads() functions #105182

Closed
vstinner opened this issue Jun 1, 2023 · 0 comments
Closed

C API: Remove PyEval_AcquireLock() and PyEval_InitThreads() functions #105182

vstinner opened this issue Jun 1, 2023 · 0 comments
Labels
topic-C-API type-bug An unexpected behavior, bug, or error

Comments

@vstinner
Copy link
Member

vstinner commented Jun 1, 2023

Since 3.7, PyEval_ThreadsInitialized() always returns non-zero and calling PyEval_InitThreads() is useless: Py_Initialize() now always creates the GIL. These functions were deprecated in Python 3.9 by PR #18892 (commit b4698ec) of issue #84058. What's New in Python 3.9:

* The :c:func:`PyEval_InitThreads` and :c:func:`PyEval_ThreadsInitialized`
  functions are now deprecated and will be removed in Python 3.11. Calling
  :c:func:`PyEval_InitThreads` now does nothing. The :term:`GIL` is initialized
  by :c:func:`Py_Initialize()` since Python 3.7.
  (Contributed by Victor Stinner in :issue:`39877`.)

Well, the removal missed Python 3.11.

PyEval_AcquireLock() and PyEval_ReleaseLock() don't update the current thread state and were deprecated in Python 3.2 by issue #55122:

These two functions are very low-level and no good to use outside the interpreter core (actually, inside the core I don't think they are useful either). We should deprecate them and recommend the thread-state aware functions instead. See issue #44960 for an example confusion.

The commit ebeb903 adds this entry to What's New in Python 3.2:

* The misleading functions :c:func:`PyEval_AcquireLock()` and
  :c:func:`PyEval_ReleaseLock()` have been officially deprecated.  The
  thread-state aware APIs (such as :c:func:`PyEval_SaveThread()`
  and :c:func:`PyEval_RestoreThread()`) should be used instead.

I propose to now removed these 4 deprecated functions.

In 2020, I already proposed to remove PyEval_AcquireLock() and PyEval_ReleaseLock() functions in https://bugs.python.org/issue39998 But I closed my issue when I discovered that they were part of the stable ABI. This is way to keep these functions in the stable ABI and remove them in the C API.

Linked PRs

@vstinner vstinner added the type-bug An unexpected behavior, bug, or error label Jun 1, 2023
vstinner added a commit to vstinner/cpython that referenced this issue Jun 1, 2023
Remove functions in the C API:

* PyEval_AcquireLock()
* PyEval_ReleaseLock()
* PyEval_InitThreads()
* PyEval_ThreadsInitialized()

But keep these functions in the stable ABI.
vstinner added a commit that referenced this issue Jun 1, 2023
)

Remove functions in the C API:

* PyEval_AcquireLock()
* PyEval_ReleaseLock()
* PyEval_InitThreads()
* PyEval_ThreadsInitialized()

But keep these functions in the stable ABI.

Mention "make regen-limited-abi" in "make regen-all".
@vstinner vstinner closed this as completed Jun 1, 2023
musicinmybrain added a commit to musicinmybrain/grpc that referenced this issue Nov 2, 2023
Since Python 3.7, it’s called by Py_Initialize and doesn’t need to be called manually, so this removal has no effect.

Since Python 3.9, it does nothing, and in Python 3.13, it will be removed, which makes this change necessary.

References:

https://docs.python.org/3/c-api/init.html#c.PyEval_InitThreads

python/cpython#105182
musicinmybrain added a commit to musicinmybrain/grpc that referenced this issue Nov 2, 2023
Since Python 3.7, it’s called by Py_Initialize and doesn’t need to be called manually, so this removal has no effect.

Since Python 3.9, it does nothing, and in Python 3.13, it will be removed, which makes this change necessary.

References:

https://docs.python.org/3/c-api/init.html#c.PyEval_InitThreads

python/cpython#105182
gnossen pushed a commit to grpc/grpc that referenced this issue Nov 2, 2023
Since Python 3.7, it’s called by
[`Py_Initialize`](https://docs.python.org/3/c-api/init.html#c.Py_Initialize)
and doesn’t need to be called manually, so this removal has no effect.

Since Python 3.9, it does nothing, and in [Python
3.13](https://docs.python.org/3.13/whatsnew/3.13.html), it [will be
removed](python/cpython#105182), which makes
this change necessary.

References:

https://docs.python.org/3/c-api/init.html#c.PyEval_InitThreads

python/cpython#105182

----

Together with the changes discussed in
#33918 and with a [Cython
fix](cython/cython#5791) to be released in
3.0.5, this allowed us to build and test our `grpc` package with Python
3.13.0a1 and Cython 3.0.4.


<!--

If you know who should review your pull request, please assign it to
that
person, otherwise the pull request would get assigned randomly.

If your pull request is for a specific language, please add the
appropriate
lang label.

-->
yarda added a commit to yarda/urh that referenced this issue Apr 4, 2024
According to https://docs.python.org/3.13/whatsnew/3.13.html:

Remove PyEval_InitThreads() and PyEval_ThreadsInitialized() functions, deprecated in Python 3.9.
Since Python 3.7, Py_Initialize() always creates the GIL:
calling PyEval_InitThreads() did nothing and PyEval_ThreadsInitialized() always returned non-zero.
(Contributed by Victor Stinner in python/cpython#105182.)

If support for < python-3.7 is required, conditionals have to be added

Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
jopohl pushed a commit to jopohl/urh that referenced this issue Apr 6, 2024
According to https://docs.python.org/3.13/whatsnew/3.13.html:

Remove PyEval_InitThreads() and PyEval_ThreadsInitialized() functions, deprecated in Python 3.9.
Since Python 3.7, Py_Initialize() always creates the GIL:
calling PyEval_InitThreads() did nothing and PyEval_ThreadsInitialized() always returned non-zero.
(Contributed by Victor Stinner in python/cpython#105182.)

If support for < python-3.7 is required, conditionals have to be added

Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-C-API type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

2 participants