[posix] E: Implement pthread_once and accept pthread_key_create destructors

[esaurez]

Summary

Implement two related libposix gaps that together block any OpenSSL 3 consumer (Python's _ssl / _hashlib, openssl CLI tooling, anything that goes through EVP_* / SSL_*):

1. pthread_once — was a no-op stub (this PR resolves [posix] Support pthread_once() nanvix/nanvix#513) that returned 0 without ever invoking init_routine. Every consumer that uses pthread_once for lazy initialization (OpenSSL, libstdc++ static init, glib, ICU, …) was silently never initialised.

2. pthread_key_create — rejected non-NULL destructors with OperationNotSupported. OpenSSL's ossl_init_thread always passes a destructor (defensive practice) so the call fails. With pthread_once fixed, this was the very next step in OpenSSL's init chain to break.

Why this matters now

OpenSSL 3 routes every internal one-time init through pthread_once (crypto/threads_pthread.c:684 → RUN_ONCE macro at include/internal/thread_once.h:129):

• OPENSSL_init_crypto returns 0
• Provider registry never populated
• EVP_MD_fetch("SHA2-256") returns NULL
• SSL_CTX_new() returns NULL with empty error queue
• Python sees _hashlib.UnsupportedDigestmodError: unsupported hash type sha256 and ssl.SSLError: unknown error (_ssl.c:3076)

This was the long-documented "OpenSSL init-order quirk" from cpython Phase 3 (esaurez/cpython#10) where the prediction was "the Group B unbundling will fix it for free". The prediction was correct in spirit but the unbundling on its own surfaces the real underlying cause: the Nanvix pthread_once stub.

Implementation

pthread_once — src/libs/posix/src/pthread/mod.rs

4-state machine encoded in init_executed, mirroring musl libc's encoding so the future MT upgrade is a mechanical rewrite (swap read_volatile/write_volatile for AtomicI32::load(Acquire)/store(Release) + futex wait/wake):

Value	State
0	NEVER_RUN (matches PTHREAD_ONCE_INIT)
1	DONE
2	IN_PROGRESS
3	WAIT (reserved for future MT — unused in ST)

Key properties:

• Fast path: volatile read of init_executed; if DONE, acquire compiler fence + return. No-op on single-CPU runtime, required when SMP lands.
• Slow path: transition NEVER_RUN → IN_PROGRESS, run init_routine, transition IN_PROGRESS → DONE with a release fence.
• Cancellation safety: a Rust Drop guard resets to NEVER_RUN if init_routine panics/unwinds — POSIX-compliant ("the effect on once_control shall be as if pthread_once() was never called").
• Sanity check: is_initialized != 1 → EINVAL (catches PTHREAD_ONCE_INIT misuse).
• Recursive same-control calls (POSIX undefined): logged, returns 0 without re-running. Sensible default over deadlock; matches the contract of "don't re-run".

The 4-state encoding is documented inline; the multi-threaded upgrade path is sketched in a comment block. The struct already has init_executed, which doubles as the futex word for the upgrade.

pthread_key_create — src/libs/syscall/src/pthread/bindings/pthread_key_create.rs

Drop the destructor-is-some hard error. Log a one-line warning and continue. Worst case is a per-thread resource leak at thread exit, which is benign in the single-threaded user-space model. Once thread-exit destructor support lands, the warning will get removed.

pthread_once_t accessors — src/libs/sysapi/src/sys_types.rs

Added pub fn is_initialized(), init_executed(), set_init_executed(), init_executed_ptr() (the last for the volatile / future-atomic state-machine word). The struct fields stay private; the accessors let libposix::pthread_once operate on the state-machine word without exposing internal layout.

Validation

Standalone C probe (statically linked OpenSSL 3.5.0 + libposix)

Before:

PROBE: OPENSSL_init_crypto=0
PROBE: OSSL_PROVIDER_load=0x0
PROBE: EVP_MD_fetch=0x0
PROBE_FAIL

After:

PROBE: OPENSSL_init_crypto=1
PROBE: OSSL_PROVIDER_load=0x6001fa70
PROBE: EVP_MD_fetch=0x60031d70
PROBE_PASS

Python end-to-end on cpython.elf

STEP_1:python_started (3, 12, 3)
STEP_2:_hashlib imported /lib/python3.12/lib-dynload/_hashlib.cpython-312.so
STEP_3:sha256 digest=a7f9173ca23c3e497cdc2e9cb1e7a238c59f2c02dc7e5a17f9dadc8860d801a5
STEP_4:_ssl imported /lib/python3.12/lib-dynload/_ssl.cpython-312.so
STEP_5:SSLContext created proto=TLS_CLIENT
STEP_6:openssl_sha256 direct digest=2d711642b726b044...
STEP_7:_hashlib and hashlib agree
OPENSSL_CHAIN_PASS

STEP_6 fixes the long-documented init-order bug where _hashlib.openssl_sha256(b"x") called as the first OpenSSL API in the process returned UnsupportedDigestmodError.

Regression tests

• LXML_CHAIN_PASS ([nanvix] E: Phase 4 — build lxml C extensions as .so (unbundled) cpython#11 path)
• CTYPES_CHAIN_PASS ([nanvix] E: Unbundle libffi via DT_NEEDED libffi.so cpython#14 path)

What's not in scope (deliberately)

• Real thread-exit destructor invocation for pthread_key_create. Out of scope for this PR; the warning will get removed when implemented.
• Multi-threaded pthread_once. The single-threaded variant is what current Nanvix needs; the comment block in the code documents the mechanical upgrade. Doing the upgrade requires futex_wait/futex_wake (or equivalent) in libposix, which doesn't exist yet.
• #[repr(C, packed)] on pthread_once_t — flagged in the research as a future MT correctness concern (atomic accesses require alignment). Doesn't matter for the ST single-CPU implementation, but should be revisited at the MT upgrade. Left as-is to not change the libc ABI.

Closes

• Resolves [posix] Support pthread_once() nanvix/nanvix#513.

Downstream consumers

• esaurez/openssl feat/build-shared-library — produces libcrypto.so + libssl.so. Functionally requires this PR at runtime.
• esaurez/cpython feat/phase3b-unbundle-openssl — Phase 3b CPython unbundling that switches _ssl / _hashlib to dlopen the .so chain. Functionally requires this PR.

Both downstream PRs are independently complete and will be filed once this lands.

[esaurez]

Superseded by upstream PR nanvix#2481, which carries the same diff (cherry-picked onto upstream/dev, deep-reviewed, with esaurez/* and cpython-migration references stripped). Two SHOULD-FIX findings from the deep review were applied: (a) eliminated &mut pthread_once_t materialisation to avoid Stacked-Borrows UB on the recursive-call path the implementation explicitly supports (raw-pointer accessors added to sysapi); (b) rewrote OnceGuard comment to honestly describe its forward-compat scope (no panic-unwind across extern C, no pthread_cancel today, panic=abort in release). Closing this fork PR; tracking continues upstream.