Re: Would an increase to PTHREAD_KEYS_MAX be an example of a FreeBSD ABI change? (lang/rust involved in why I ask)

On 5/14/26 14:11, Konstantin Belousov wrote:
> On Thu, May 14, 2026 at 11:30:10AM -0700, Mark Millard wrote:
>> Would an increase to PTHREAD_KEYS_MAX be an example of a FreeBSD ABI change?
>>
>>
>> Why I ask: an active failure for at least rust use on armv7 . . .
>>
>> The armv7 1.94.0 rust-bootstrap used to try to build 1.95.0 of lang/rust
>> for armv7 gets the Thread Local Storage failure "Out of TLS keys".
>>
>> The same was true for the armv7 1.93.0 rust-bootstrap used to try to
>> build the armv7 1.94.0:
>>
>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294545>
>> (Robert Clausecker, not me.)
>>
>>
>> OpenBSD increased PTHREAD_KEYS_MAX to 512 to avoid getting such "Out of
>> TLS keys" failures, not necessarily for armv7 or for building rustc:
>>
>> <https://github.com/openbsd/src/commit/f90c65410264d8346b711e36bca7ee1f0dde5ca9>
>> (2025-11-11)
>>
>> QUOTE from OpenBSD's commit:
>> bump PTHREAD_KEYS_MAX to 512
>> the rust libstd emutls version is using one pthread_key per
>> thread-variable. it means the maximum number of thread-variable at a
>> time is PTHREAD_KEYS_MAX.
>>
>> with recent rustc 1.91.0, we start hiting the limit while compiling some
>> programs (like sysutils/rustic).
>>
>> ok robert@
>> "Let's go 512 and hope someone eventually does proper TLS" deraadt@
>> END QUOTE
>>
>> I think they had 256 previous to the change, not just 128.

The FreeBSD source has indications of both 128 and 256, as it turns
out:

# grep -r "define.*THREAD_KEYS_MAX" /usr/include/ /usr/src/
/usr/include/limits.h:#define	_POSIX_THREAD_KEYS_MAX	128
/usr/include/pthread.h:#define	PTHREAD_KEYS_MAX			256
/usr/include/unistd.h:#define	_SC_THREAD_KEYS_MAX	86 /* user */
/usr/src/include/unistd.h:#define	_SC_THREAD_KEYS_MAX	86 /* user */
/usr/src/include/limits.h:#define	_POSIX_THREAD_KEYS_MAX	128
/usr/src/include/pthread.h:#define	PTHREAD_KEYS_MAX			256

With:
        case _SC_THREAD_KEYS_MAX:
                return (PTHREAD_KEYS_MAX);

(Thanks to Robert C. for pointing this out.)

For reference:

# grep -r _POSIX_THREAD_KEYS_MAX /usr/include/ /usr/src/
/usr/include/limits.h:#define	_POSIX_THREAD_KEYS_MAX	128
/usr/src/contrib/netbsd-tests/include/t_limits.c:#ifdef
_POSIX_THREAD_KEYS_MAX
/usr/src/contrib/netbsd-tests/include/t_limits.c:	{
"_POSIX_THREAD_KEYS_MAX",	_POSIX_THREAD_KEYS_MAX,		128  },
/usr/src/usr.bin/getconf/limits.gperf:_POSIX_THREAD_KEYS_MAX,
_POSIX_THREAD_KEYS_MAX
/usr/src/include/limits.h:#define	_POSIX_THREAD_KEYS_MAX	128

So 128 looks to not be used for much.

>>
>> (The "libstd emutls version" may not be always involved for rust's
>> context? Also: the failure type is apparently not limited to building
>> the rust compiler/toolchain. The overall issue is not FreeBSD OS specific.)
>>
>>
>> Note: It appears that the official FreeBSD port-package building for
>> armv7 stopped shortly before this started to be an issue. That is why
>> fallout reports have not been accumulating for the "out of TLS keys" issue.
>>
>>
>> If increasing PTHREAD_KEYS_MAX is an ABI change, an implication is that
>> 14.*-RELEASE and 15.*-RELEASE could not be changed, possibly eliminating
>> rust use on armv7 going forward.
>>
>>
>> Note:
>> It is my understanding that alternate Thread Local Storage models for
>> rust require use of rust-nightly (unstable) builds instead of stable
>> rust builds.
> 
> Surely increasing the value would be ABI breaking change, but perhaps
> this is the change that we can tolerate.
> 
> OTOH, we do have compiler-supported TLS, so I am at least curious why
> Rust doesn't use it.
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com