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

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