| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Build fails on macOS with Clang 12.0.0 (clang-1200.0.32.27): "illegal thread local variable reference" building 'math' extension gcc -Wno-unused-result -Wsign-compare -g -O0 -Wall -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I./Include -I. -I/usr/local/include -I/Users/runner/work/cpython/cpython/Include -I/Users/runner/work/cpython/cpython -c /Users/runner/work/cpython/cpython/Modules/mathmodule.c -o build/temp.macosx-10.15-x86_64-3.10-pydebug/Users/runner/work/cpython/cpython/Modules/mathmodule.o -DPy_BUILD_CORE_MODULE gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.15-x86_64-3.10-pydebug/Users/runner/work/cpython/cpython/Modules/mathmodule.o Modules/_math.o -L/usr/local/lib -lm -o build/lib.macosx-10.15-x86_64-3.10-pydebug/math.cpython-310d-darwin.so ld: illegal thread local variable reference to regular symbol __Py_current_tstate for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) |
Sorry, something went wrong.
|
On MSC, we can try to use __declspec(thread). I tried but I got an error about DLL export. Maybe it should not be exported, and so the variables should not be used when building an extension module (not built as a builtin module). |
Sorry, something went wrong.
|
cc @markshannon who loves TLS :-) |
Sorry, something went wrong.
|
See https://bugs.python.org/issue40522#msg383899 for the emitted assembly code. |
Sorry, something went wrong.
|
See also https://stackoverflow.com/questions/18298280/how-to-declare-a-variable-as-thread-local-portably |
Sorry, something went wrong.
|
"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." |
Sorry, something went wrong.
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: * 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 #define Py_ThreadLocal(type, varname) ... in pyport.h? |
Sorry, something went wrong.
|
One other remark (not for this PR, but for future work): |
Sorry, something went wrong.
|
I need to test -femulated-tls clang flag. See also: http://llvm.org/docs/LangRef.html#thread-local-storage-models |
Sorry, something went wrong.
|
This PR is stale because it has been open for 30 days with no activity. |
Sorry, something went wrong.
|
@vstinner Did you ever get anywhere with this? |
Sorry, something went wrong.
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). |
Sorry, something went wrong.
Or simply mandate C99? It's been >20 years... |
Sorry, something went wrong.
See previous comments. I got compiler errors to use this "recent feature". Sorry, the feature comes from C11, not C99. I don't call. |
Sorry, something went wrong.
|
I failed finding time to fix compiler errors. I prefer to abandon this PR for now. |
Sorry, something went wrong.
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).)
| Back | FazBrowse Home | New Git URL |
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