[libcxx-commits] [libcxx] [libc++] atomic_wait refactor experiment (PR #85086)

[Louis Dionne via libcxx-commits]

================
@@ -71,19 +71,27 @@ struct __atomic_wait_poll_impl {
 
 #ifndef _LIBCPP_HAS_NO_THREADS
 
-_LIBCPP_AVAILABILITY_SYNC _LIBCPP_EXPORTED_FROM_ABI void __cxx_atomic_notify_one(void const volatile*);
-_LIBCPP_AVAILABILITY_SYNC _LIBCPP_EXPORTED_FROM_ABI void __cxx_atomic_notify_all(void const volatile*);
-_LIBCPP_AVAILABILITY_SYNC _LIBCPP_EXPORTED_FROM_ABI __cxx_contention_t __libcpp_atomic_monitor(void const volatile*);
-_LIBCPP_AVAILABILITY_SYNC _LIBCPP_EXPORTED_FROM_ABI void __libcpp_atomic_wait(void const volatile*, __cxx_contention_t);
-
-_LIBCPP_AVAILABILITY_SYNC _LIBCPP_EXPORTED_FROM_ABI void
-__cxx_atomic_notify_one(__cxx_atomic_contention_t const volatile*);
-_LIBCPP_AVAILABILITY_SYNC _LIBCPP_EXPORTED_FROM_ABI void
-__cxx_atomic_notify_all(__cxx_atomic_contention_t const volatile*);
-_LIBCPP_AVAILABILITY_SYNC _LIBCPP_EXPORTED_FROM_ABI __cxx_contention_t
-__libcpp_atomic_monitor(__cxx_atomic_contention_t const volatile*);
-_LIBCPP_AVAILABILITY_SYNC _LIBCPP_EXPORTED_FROM_ABI void
-__libcpp_atomic_wait(__cxx_atomic_contention_t const volatile*, __cxx_contention_t);
+struct __atomic_waitable_contention_self {
+  volatile __cxx_atomic_contention_t* __waiter_count_;
+  const volatile __cxx_atomic_contention_t* __platform_state_;
+
+  _LIBCPP_AVAILABILITY_SYNC _LIBCPP_EXPORTED_FROM_ABI __atomic_waitable_contention_self(const volatile __cxx_atomic_contention_t*);
----------------
ldionne wrote:

We would have to introduce a new availability macro, something like `_LIBCPP_AVAILABILITY_SYNC_NEW_IMPLEMENTATION` or whatever. And then based on `_LIBCPP_AVAILABILITY_HAS_SYNC_NEW_IMPLEMENTATION` we would use the old or the new implementation from the dylib.

In order for this to be manageable, we'd have to funnel all the things that end up calling into the dylib through a set of functions where the `#ifdef`s can live.

https://github.com/llvm/llvm-project/pull/85086