@colesbury Can I take a look at it?

@corona10 - of course, thanks!

Note that checking if __builtin_thread_pointer() is available is not trivial. __has_builtin(__builtin_thread_pointer) is not useful (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96952). You need some combination of platform and GCC/clang version check.

That's fine. We have many tests preprocessor checks like that, #if ....

@colesbury Do we need to support more platforms or we can close the issue?

I think we still want the cross-platform fallback that returns the address of a thread-local variable. That will probably need to be implemented in a .c file because accessing thread-local variables across libraries can cause issues on some platforms.

FYI, PEP 11 defines which platform we should cover :)
According to PEP 11, WASM is left but IIRC, Support thread feature from WASM side is quite early stage: https://github.com/WebAssembly/wasi-threads
https://peps.python.org/pep-0011/

Adding a fallback will ease the maintenance burden and also work with WASM. In general, I think we want portable implementations when possible even if the platforms listed in PEP 11 ought to work without them.

We can't use _Py_ThreadId() outside of the --disable-gil builds right now. That makes it harder to implement an efficient recursive lock. We still will not want to expose _Py_ThreadId() outside of --disable-gil builds, but it will be convenient to use it in .c files like Python/lock.c.

Well, we already implemented PyThread_get_thread_native_id for getting native thread id. Do you want to use same approach as the fallback?
If yes, Which platforms do we have to care about? (Linux Only? or other things too?)

@corona10, no I don't think we should use PyThread_get_thread_native_id. I think we should do what I wrote as part (2) in the issue: "return the address of a thread-local variable"

Got it, I will send a PR soon. I read TLS spec in here and now I understand what you want to say.(maybe?)

@corona10, here is an example of what I mean in mimalloc, which uses the same strategy on platforms where it doesn't implement a faster _mi_prim_thread_id():

My reasons for preferring this strategy instead of PyThread_get_thread_native_id() are:

1. It should be a lot faster than PyThread_get_thread_native_id() (no syscalls), although still not as fast as the platform-specific implementations currently used in _PyThread_Id()
2. We can make more assumptions about the format (i.e., non-zero, pointer-aligned), which I think will come in handy when implementing recursive mutexes.

You may have a look at _PyThreadState_GET() which is implemented by reading a thread local variable. If Py_BUILD_CORE_MODULE macro is defined, the function is implemented with an opaque function call: implementation for libraries.

Got it, I will send a PR soon.

I am going to submit the PR early next week :)

Okay, let's close the issue since the fallback implementation is merged.
Thank you for all your supports and contribution @colesbury, @vstinner(Awesome test codes!) and @furkanonder (RISC-V)

Now, we can support free-threaded CPython for all platforms where the fallback implementation(it only requires thread-local feature) works!