Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork33.3k
bpo-40522: Store tstate in a Thread Local Storage#23976
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Build fails on macOS with Clang 12.0.0 (clang-1200.0.32.27): "illegal thread local variable reference" |
On MSC, we can try to use |
cc@markshannon who loves TLS :-) |
Seehttps://bugs.python.org/issue40522#msg383899 for the emitted assembly code. |
"In C11, the keyword _Thread_local is used to define thread-local variables. The header <threads.h>, if supported, defines thread_local as a synonym for that keyword." |
If Python is built with GCC or clang, the current interpreter and thecurrent Python thread state are now stored in a Thread Local Storage.Changes:* configure checks for C11 _Thread_local keyword.* Use _Thread_local keyword, GCC and clang __thread extension.* Add set_current_tstate() sub-function which sets these two new TLS variables (if available).* _PyThreadState_Swap() and _PyThreadState_DeleteCurrent() now call set_current_tstate().* _PyThreadState_GET() and _PyInterpreterState_GET() now use the TLS variable if available.
Would it be possible to keep all the portability macros in one place by putting something like |
One other remark (not for this PR, but for future work): |
I need to test |
This PR is stale because it has been open for 30 days with no activity. |
@vstinner Did you ever get anywhere with this? |
I got compiler issues and then I stopped working on this PR. A compromise would be to find a way to use a C99 keyword internally, but use a function call externally. "externally" includes stdlib modules built as shared libraries (Linux .so, Windows .dll). |
Or simply mandate C99? It's been >20 years... |
See previous comments. I got compiler errors to use this "recent feature". Sorry, the feature comes from C11, not C99. I don't call. |
I failed finding time to fix compiler errors. I prefer to abandon this PR for now. |
gh-103324)We replace _PyRuntime.tstate_current with a thread-local variable. As part of this change, we add a _Py_thread_local macro in pyport.h (only for the core runtime) to smooth out the compiler differences. The main motivation here is in support of a per-interpreter GIL, but this change also provides some performance improvement opportunities.Note that we do not provide a fallback to the thread-local, either falling back to the old tstate_current or to thread-specific storage (PyThread_tss_*()). If that proves problematic then we can circle back. I consider it unlikely, but will run the buildbots to double-check.Also note that this does not change any of the code related to the GILState API, where it uses a thread state stored in thread-specific storage. I suspect we can combine that with _Py_tss_tstate (from here). However, that can be addressed separately and is not urgent (nor critical).(While this change was mostly done independently, I did take some inspiration from earlier (~2020) work by@markshannon (main...markshannon:threadstate_in_tls) and@vstinner (#23976).)
Uh oh!
There was an error while loading.Please reload this page.
If Python is built with GCC or clang, the current interpreter and the
current Python thread state are now stored in a Thread Local Storage.
Changes:
variables.
variables (if available).
set_current_tstate().
variable if available.
https://bugs.python.org/issue40522