USE=threads is problematic. Its behaviour is not well-defined and it's certainly not well suited to being a global USE flag at the very least (where a flag should have similar/consistent behaviour across all packages). Packages with USE=threads should instead: 1) always enable the threading behaviour if it's upstream's default & well-tested; or 2) always disable the threading behaviour if it's an untested codepath and non-default (think e.g. pre-pthreads implementation, or npth-like, although one might be able to make a case for npth usage); or 3) default to upstream's configuration (or a reasonable well-tested configuration) but add a USE flag for some other behaviour like asynchronous support (e.g. USE=adns in net-misc/curl, but when USE=-adns, curl still uses pthreads now); 4) at the very, very least, write something descriptive in metadata.xml. Certainly, no matter what, USE=threads in make.conf should not lead to harmful effects. The default case should also be performant. Quoting a recent commit to net-misc/curl: ``` commit bd4d42f83c774c36bf879a5b7ec89d373546743e Author: Sam James <sam@gentoo.org> Date: Thu Sep 1 22:42:26 2022 +0100 net-misc/curl: drop USE=threads USE=threads is a terrible USE flag (not the fault of net-misc/curl or its maintainer) and we're looking to get rid of it entirely. This is motivated further by the fact users have USE=threads in make.conf seeking performance improvements and such (which is understandable) but as per below, it can lead to conflicting and inconsistent effects. (In particular, anyone with USE="threads" in make.conf (don't do this for the reasons below!) will end up with a REQUIRED_USE issue between the now-default USE=adns and USE=threads). There are a few possibilities with threads support: 1. Upstreams always have threads support (hence USE=threads is only affecting a "handful" of packages anyway, not every single package, as many will just always be using pthreads and there's no way of disabling it); 2. The "threads" toggle means enabling some experimental or legacy implementation (think e.g. dev-lang/perl, which uses USE=ithreads for this, as it breaks ABI) (also applies to net-misc/curl given USE=threads doesn't help with the adns functionality many applications desire, see linked bug); 3. Not having "threads" on enables some experimental or legacy implementation again (this *again* applies to net-misc/curl given USE="-adns -threads" leaves us with a dodgy implementation as well). Commit 60b7aaa7a70149751446237d7207ff1ca20c256e enabled adns by default (IUSE=+adns). This commit drops USE=threads entirely and makes the default pthreads with adns opt-in with IUSE=+adns still. Now, the ebuild previously had REQUIRED_USE="threads? ( !adns )". I can't see a reason for this other than making the previous situation "meaningful", i.e. allowing people to decisively choose which is used at runtime, as while curl can build with both threads and adns, I think adns ends up preferred at runtime. With this change and given all of the above, we actually want adns to take priority if it's set, as threads will just be the default, so drop the REQUIRED_USE. Bug: https://bugs.gentoo.org/699632 See: 60b7aaa7a70149751446237d7207ff1ca20c256e Signed-off-by: Sam James <sam@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/27111 Signed-off-by: Sam James <sam@gentoo.org> ```
