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.
