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).