Build failure without thread local support

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

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.

@ZeroIntensity

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

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"

@velemas

@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

@colesbury

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

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.

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

@ZeroIntensity

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

This commit fixes the issue pythongh-127865.

gh-127865: Fix build failure for systems without thread local support (…

pythongh-127865: Fix build failure for systems without thread local s…

[3.13] gh-127865: Fix build failure for systems without thread local …

Thanks!

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.

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

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.

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.

pythongh-127865: Fix build failure for systems without thread local s…

Navigation Menu

Repository navigation

Build failure without thread local support #127865

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	#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"

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

Build failure without thread local support #127865

Description

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

Activity

ZeroIntensity commented on Dec 12, 2024

velemas commented on Dec 12, 2024

colesbury commented on Dec 12, 2024

colesbury commented on Dec 12, 2024

velemas commented on Dec 12, 2024

velemas commented on Dec 12, 2024

ZeroIntensity commented on Dec 12, 2024

velemas commented on Dec 12, 2024

colesbury commented on Dec 12, 2024

ZeroIntensity commented on Dec 12, 2024

colesbury commented on Dec 12, 2024

ZeroIntensity commented on Dec 13, 2024

velemas commented on Dec 13, 2024

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions