[libcxx-commits] [libcxx] [libc++] Use Fuchsia futex operations (PR #133571)

[via libcxx-commits]

================
@@ -254,6 +258,37 @@ static void __platform_wake_by_address(void const* __ptr, bool __notify_one) {
   }
 }
 
+#elif defined(__Fuchsia__)
+
+template <std::size_t _Size>
+static inline zx_futex_t const* __get_zx_futex(void const* __ptr) {
+  static_assert(_Size == sizeof(zx_futex_t), "Can only wait/wake on zx_futex_t-compatible value");
+
+  // Implicitly link against the vDSO system call ABI without requiring the
+  // final link to specify -lzircon explicitly when statically linking libc++.
+#  pragma comment(lib, "zircon")
+
+  return reinterpret_cast<zx_futex_t const*>(__ptr);
----------------
huixie90 wrote:

just wanted to bring you attention of 
libcxx/include/__atomic/atomic_waitable_traits.h

and here is the design intent of how things work.

atomic_waitable_traits.h defines a concept `__has_native_atomic_wait` that decides which types can directly call the platform futex wait, and which types needs to go through the global contention table proxy for platform wait.

And there are two ABI modes. 

For the default ABI, `__has_native_atomic_wait` basically says only the `__cxx_contention_t` satisfies,  which is `int32_t` in your case,  can directly go to platform futex wait. I assume here zx_futex_t is exactly int32_t otherwise we might have UB 

For another ABI which has `_LIBCPP_ABI_ATOMIC_WAIT_NATIVE_BY_SIZE` defined, which is controlled by the platform owner. in this case, i believe your platform does not enable it. but say, one day you decide to enable this ABI, the way it works is that.  you can define `__has_native_atomic_wait` the way you want, the default concept in this mode is: any trivially copyable type with unique value representations, whose sizes matches `__cxx_contention_t`.  in this case, `__ptr` and `__val` can be pointers to a wide range of types, e.g. a `uint32_t`, `struct S { int32_t i;};` etc... In which case, I am not sure how `reinterpret_cast<zx_futex_t const*>` can be well defined.  (anyway you don't need to worry about this if you don't plan to enable this ABI)


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