-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
Rename PyGILState_Check() #131264
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
Comments
FTR, there's a recent proposal that discusses some of the related name issues: https://discuss.python.org/t/a-new-api-for-ensuring-releasing-thread-states/83959. |
I'm pretty much against any new APIs with "GIL" in the name, because they're not very intuitive for free-threading. How about |
FWIW, "HoldsTstate" doesn't mean much to me. |
Yeah, there's not a good correlation between thread states and the GIL (yet, hopefully). If we want to stay away from thread states, how about something like |
|
Not exactly, but everything GIL-related at the time was probably |
Yeah, sounds about right. 😄 |
You're probably right. |
Uh oh!
There was an error while loading. Please reload this page.
Feature or enhancement
Proposal:
Nearly all of the C-API expects that the current thread holds the GIL when called. Mostly, users of the C-API had to know before calling the C-API. Beck in the day it wasn't obvious how. This was the motivation behind adding
PyGILState_Check()
.The key point in this issue is that the name
PyGILState_Check()
unnecessarily associates the capability with thePyGILState_*
API. Users would benefit from a different function name. I'd think something likePy_HoldsGIL()
would be better.Why was the function added as
PyGILState_Check()
? Perhaps @kristjanvalur remembers. It was added in 2013, 10 years after the PEP 311 implementation, so it's not because it was part of the PEP. I'd guess it's mostly because it was implemented usingPyGILState_GetThisThreadState()
.It's also notable that a lot of things have changed in the runtime since 2013. At the time
PyGILState_Check()
was added:PyThreadState_Get()
(orPyThreadState_GET()
) to get the tstate active in the current thread, but only if it held the GILPyGILState_GetThisThreadState()
PyThreadState_IsCurrent()
that sort of merged the twoHere some of the developments since then:
Here's the history in some detail:
(expand)
PyThreadState_Get()
exposes itPyThreadState_Swap()
modifies itPyThreadState_GET()
macro (commit 275ea67)PyGILState_*
API (commit 8d98d2c),autoTLSkey
)PyGILState_GetThisThreadState()
exposes itPyThreadState_IsCurrent()
that indicates if that thread-local tstate holds the GILPyGILState_Check()
does not exist yetPyGILState_Check()
added (Add api PyGILState_Check #61724, commit 684cd0e)PyThreadState_IsCurrent(PyGILState_GetThisThreadState())
_PyRuntimeState
added (commit 2ebc5ce)_PyThreadState_Current
) to_PyRuntime.gilstate.tstate_current
_PyRuntime.gilstate
_PyRuntime.ceval.gil
_PyThreadState_GET()
, without NULL check (commit 50b4857)_PyRuntime.gilstate.tstate_current
to_PyRuntime.tstate_current
(commit 6036c3e)current_thread_holds_gil
(commit 92d8bff)PyThreadState._status.holds_gil
(commit be1dfcc)Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
The text was updated successfully, but these errors were encountered: