The Rust programming language is currently trying to replace its synchronization primitives with more efficient, statically initializable ones (see tracking issue). This turned out to be difficult on macOS, as it does neither have these primitives by default like Windows (SRWLock is really efficient and works with condition variables) or have a ready-to-use futex operation like Linux, FreeBSD, etc. A suitable alternative would be to use a parking lot like WebKit did, but that would make it impossible to implement priority-inheriting mutexes, which are somewhat important on an interactive system like macOS with its QoS feature. It turns out however, that macOS actually has a futex-like syscall called ulock_wait/ulock_wake. This syscall, while exposed through libSystem, is unfortunately private and its use has resulted in Apps being rejected from the App Store, which is unacceptable for a standard library like std. Since it is implemented since macOS 10.12, retroactively stabilizing the API would make it possible for all Apps, including WebKit, to use custom, more efficient (pthread_mutex_t needs a heap-allocation of 64 bytes) synchronization primitives. Another option would be to use os_unfair_lock for the mutex implementation and use userspace alternatives for CondVar and RwLock. However, the documentation of os_unfair_lock does not guarantee that the lock is movable while not locked, even though it works in practice. Could that guarantee be added to its API? Do you see any other alternatives? Lazily allocating the pthread_mutex_t is the strategy currently chosen, but that does not mitigate certain unsoundness problems, which is something Rust likes to avoid.

The Rust standard library wants to use the os_sync_wait_on_address family of functions to implement its synchronization primitives (my PR). Unfortunately, this API is only available starting with macOS 14.4 and iOS 17.4, which are way above our minimum supported versions (macOS 10.12 and iOS 10). The private API underlying os_sync_wait_on_address (__ulock_wait) is available however, starting with exactly these versions. Thus, Rust wants to use these functions as a fallback when the public API is not available. To ensure that code using Rust does not break if and when the private functions get removed, we'll use dlsym to look them up dynamically. The question now is just whether using dlsym to access private API in this way is allowed by the App Store guidelines – we'd very much like to avoid breaking the workflow of our users. Thank you, Jonas