Waiting with a timeout

[m-ou-se]

This crate currently does not have support for waiting with a timeout.

Following up on the question from this comment:

Is this because of macOS?

Yes.

macOS does have the __ulock_wait syscall that do support a timeout, but it's a private/unstable API as far as I know. Usage of private APIs can result in software being rejected from Apple's app stores, and that seems to happen for the __ulock_* APIs too: boostorg/atomic#55

So, instead, I make use of the (libc++ internal but ABI stable) functions behind the standard C++ std::atomic<T>::wait API (__libcpp_atomic_monitor and __libcpp_atomic_wait), which unfortunately don't support a timeout. :(

Is this fixable?

I see three possible solutions:

• Get Apple to expose a public API for this (e.g. mark __ulock_{wait, wake} as public); or
• Propose a new std::atomic<T>::wait with timeout to be included in the next C++ standard, wait for Apple's libc++ to include that, and defer to its implementation; or
• Implement it ourselves using a global hash table containing mutexes and condition variables, similar to how parking_lot_core does it [1]. (parking_lot_core uses a dynamically resizing hashmap [2], while libc++ uses a fixed set of 256 buckets [3].)

The last option is the most feasible in the short term, but I like how the atomic-wait crate is currently just a very thin wrapper around the native APIs, and that option would be a departure from that. It means we'll need to make trade offs about hashing algorithms and bucket sizes. Perhaps it can be done as an optional crate feature.

[AngelicosPhosphoros]

The last option is the most feasible in the short term, but I like how the atomic-wait crate is currently just a very thin wrapper around the native APIs, and that option would be a departure from that. It means we'll need to make trade offs about hashing algorithms and bucket sizes. Perhaps it can be done as an optional crate feature.

I think, if users wants something like parking_lot, they would just use it. IMHO, this crate is more relevant for people who want as simple as possible wrapper over native APIs.

[m-ou-se]

macOS 14.4+ now has the os_sync_wait family of functions, which includes os_sync_wait_on_address_with_timeout and os_sync_wait_on_address_with_deadline.

Right now, that version is too new to depend on in this crate probably. But maybe in a few years..