GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||||
GeezerVison is showing github.com — gh-112535: Update _Py_ThreadId() to support PowerPC, IBM Z, etc by corona10 · Pull Request #112553 · python/cpython Conversation
|
| __asm__ ("mrs %0, tpidrro_el0" : "=r" (tid)); | ||
| #elif defined(__aarch64__) | ||
| __asm__ ("mrs %0, tpidr_el0" : "=r" (tid)); | ||
| #elif define(HAVE_BUILTIN_THREAD_POINTER) |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
This line of the public C API which can be used by a C compiler different than the one used to build Python. I don't think that if define(HAVE_BUILTIN_THREAD_POINTER) check is reliable, according to what @colesbury wrote in the issue.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I wrote "C compiler", but the C API can be parsed by parsers which are not C compiler, but written in any programming language. Moreover, the C API is used in C++.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Ah got it, let me check :)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
. I don't think that if define(HAVE_BUILTIN_THREAD_POINTER) check is reliable
but the C API can be parsed by parsers which are not C compiler
Yeah, I thought that configuring time checking would be enough but it looks like we should consider 3rd party case.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'm concerned that the compiler for CPython may be not exactly the same as the compiler for third-party extensions. For example, if we want to use __builtin_thread_pointer() for x86-64, it's available for GCC 11.1+, but an extension might be compiling with an older version of GCC that doesn't support it for that architecture.
Additionally, one thing to be careful of, is that macOS arm64 will successfully compile and run __builtin_thread_pointer(), but it returns the wrong value (CPU id).
PowerPC on GCC still requires a "register variable" https://github.com/bminor/glibc/blob/master/sysdeps/powerpc/nptl/thread_pointer.h (or it can fallback to a portable thread-local implementation, but that would be slower.)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Maybe we should have a more global configuration: "if the compiler doesn't support _Py_ThreadId(), use opaque function calls for Py_INCREF/Py_DECREF". Maybe even give a way to opt-out from inline assembly code. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@vstinner, that might be a better strategy. It just seems more difficult than making |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
One step forward: with PR #112747, it becomes possible to use the limited C API on a free threading build. It's implemented with opaque function calls for functions which use too "low-level" functions such at the private Later, we can modify the |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.