Build failure without thread local support

[velemas]

Bug report

Bug description:

When building environments without thread local support, this build failure occurs:

~/cpython-3.13.1/Python/import.c:750: error: argument of type "PyMutex" is incompatible with parameter of type "PyThread_type_lock"
      PyThread_acquire_lock(EXTENSIONS.mutex, WAIT_LOCK);
                            ^
~/cpython-3.13.1/Python/import.c:760: error: argument of type "PyMutex" is incompatible with parameter of type "PyThread_type_lock"
      PyThread_release_lock(EXTENSIONS.mutex);
                            ^
~/cpython-3.13.1/Python/import.c:769: error: argument of type "PyMutex" is incompatible with parameter of type "PyThread_type_lock"
      PyThread_acquire_lock(EXTENSIONS.mutex, WAIT_LOCK);
                            ^
~/cpython-3.13.1/Python/import.c:774: error: argument of type "PyMutex" is incompatible with parameter of type "PyThread_type_lock"
      PyThread_release_lock(EXTENSIONS.mutex);

The issue is caused by incomplete change introduced with the commit 628f6eb from the PR #112207.

CPython versions tested on:

3.13

Operating systems tested on:

Other

Linked PRs

• gh-127865: build failure fix for systems without thread-locals support #127866
• [3.13] gh-127865: Fix build failure for systems without thread local support (GH-127866) #127882

[ZeroIntensity]

I suspect the fix is to just change that to PyMutex_Lock, but which system is this? We explicitly dropped support for systems without multithreading back in 3.7, but I'm not sure if the ability to have thread-locals falls under that umbrella.

[velemas]

@ZeroIntensity thread-locals are not necessary for multithreading.
The affected system is a mainframe.

[colesbury]

It's good to fix the erroneous calls to PyThread_acquire_lock, but I think you'll still run into:

cpython/Python/pystate.c

Lines 74 to 78 in 487fdbe

	#ifdef HAVE_THREAD_LOCAL
	return _Py_tss_tstate;
	#else
	// XXX Fall back to the PyThread_tss_*() API.
	# error "no supported thread-local variable storage classifier"

[colesbury]

@velemas what compiler and system are you using?

• Python requires C11 (without optional features) since 3.11
• _Thread_local is a non-optional part of C11. As far as I can tell it's independent of _STDC_NO_THREADS_. Some relevant discussion on Stack Overflow.

That makes me think we should adjust the condition in pyport.h to remove the _STDC_NO_THREADS_ guard:

cpython/Include/pyport.h

Lines 508 to 509 in 487fdbe

	# elif __STDC_VERSION__ >= 201112L && !defined(__STDC_NO_THREADS__)
	# define _Py_thread_local _Thread_local

[velemas]

@colesbury It is the local mainframe system compiler based on LLVM with C11 support but all C11 threading features are still missing there.

[velemas]

It's good to fix the erroneous calls to PyThread_acquire_lock, but I think you'll still run into:

cpython/Python/pystate.c

Lines 74 to 78 in 487fdbe

	#ifdef HAVE_THREAD_LOCAL
	return _Py_tss_tstate;
	#else
	// XXX Fall back to the PyThread_tss_*() API.
	# error "no supported thread-local variable storage classifier"

That part is covered with local patching by falling back to PyThread_tss_*() API as the comment suggests.

[ZeroIntensity]

What do you mean by "local patching"? The thread state doesn't fall back to PyThread_tss (it's a TODO comment).

[velemas]

@ZeroIntensity There is a port of python for the mainframe and that part is covered with the port patches from the mainframe maintainers (incl. me).

[colesbury]

Thanks!

[ZeroIntensity]

Do you think it's worth trying to fix (and test) building Python without thread locals? Using PyThread_tss shouldn't be too difficult for the thread state, but I'm not sure what other cases exist.

[colesbury]

I think the opposite: we should get rid of HAS_THREAD_LOCAL and move the #error message to pyport.h:

• All the supported platforms support thread local variables
• C11 (and C23) have thread local as part of the language
• We require C11 since Python 3.11

I don't think a PyThread_tss fallback is worth the maintenance effort just to support unnamed hardware from an unnamed company 👁️ 🐝 M.

There was a proposal WG14 N2291 for C23 to make _Thread_local dependent on __STDC_NO_THREADS__. It wasn't accepted. (I bet you can guess the author's company!)

[ZeroIntensity]

Now I'm curious what "unnamed company" has against thread locals!

Anyways, removing the macro seems reasonable if everything we support must have thread locals. It might be worth deprecating PyThread_tss too.

[velemas]

I think the opposite: we should get rid of HAS_THREAD_LOCAL and move the #error message to pyport.h:

* All the [supported platforms](https://peps.python.org/pep-0011/#support-tiers) support thread local variables

* C11 (and C23) have thread local as part of the language

* We require C11 since Python 3.11

I don't think a PyThread_tss fallback is worth the maintenance effort just to support unnamed hardware from an unnamed company 👁️ 🐝 M.

There was a proposal WG14 N2291 for C23 to make _Thread_local dependent on __STDC_NO_THREADS__. It wasn't accepted. (I bet you can guess the author's company!)

It is not 👁️ 🐝 M. The mainframe system was originally developed by Siemens. But I guess all mainframes have their hardships supporting thread locals.