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

[Louis Dionne via Phabricator via libcxx-commits]

ldionne requested changes to this revision.
ldionne added a comment.
This revision now requires changes to proceed.

I looked at the first 4-5 patches in this series, and I have a pretty big conceptual problem with this and all the little workarounds it allows creating afterwards. We already have a compile-time notion of whether threads are enabled or not and it seems really strange to me to control this sort of aspect of a program at runtime. I know that's the system you're working with and libc++ has no bearing on that, however I am pretty uneasy about opening the door to this kind of runtime customization.

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? The main motivation for this patch appears to be:

> to get a little extra performance out of single-threaded applications.

How compelling is that performance gain? How frequent are single-threaded programs? Are there other ways to achieve that performance gain without inserting such "hacks" in the code?

TL;DR: This is crossing a pretty clear cut boundary that we have never crossed before (runtime vs compile-time), and I think it's not a great idea to do that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110349