[libcxx-commits] [PATCH] D110349: [libcxx][SystemZ][z/OS] Added is_threading_api_enabled and might_have_multiple_threads to __threading_support

[Daniel McIntosh via Phabricator via libcxx-commits]

DanielMcIntosh-IBM added a comment.

In D110349#3116616 <https://reviews.llvm.org/D110349#3116616>, @ldionne wrote:

> Is there a reason why the underlying C library can't implement e.g. `mtx_lock` as a no-op if threading is disabled at runtime?

Just to clarify, z/OS doesn't use the C11 threading library for __threading_support, it uses the POSIX threading library so it would be `pthread_mutex_lock`.
I don't know if we could have the underlying `pthread_mutex_lock` and friends act as a no-op like you've described (it's managed by a separate team), but I strongly suspect it's not an option, as that could affect the behaviour of existing applications on z/OS.

However, making `__libcpp_mutex_lock` a no-op when the POSIX functions aren't available (aka `POSIX(OFF)`) might be an option, and it might work for some of the places we are making changes, but not it won't work for all of them.
For example, it won't work for D113054 <https://reviews.llvm.org/D113054>. In `POSIX(OFF)`, not only does `pthread_once` (and thus __libcpp_execute_once) not work, there's no way of allocating thread-local storage, so we'd have to implement fake versions of `__libcpp_execute_once` and all the thread local storage functions. That would still be technically feasible, but it would get very ugly very fast, and probably perform exceedingly poorly.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110349/new/

https://reviews.llvm.org/D110349