Re: [PATCH] nptl: Move pthread_equal implementation into libc

[Florian Weimer <fw at deneb dot enyo dot de>]

* Adhemerval Zanella:

> On 13/08/2019 12:58, Florian Weimer wrote:
>> Tested on x86_64-linux-gnu and i686-linux-gnu, and compile-tested using
>> build-many-glibcs.py.  No regressions related to this change.
>
> What is the motivation for this change? Simplify the internal libc
> stubs?

We only need one implementation.  The indirection from libc to
libpthread is completely unnecessary.

My goal is to get rid of the forwarders than do not depend on internal
libpthread state fairly quickly, and then move the rest once the
__libc_single_threaded flag has been around for a while (so that
applications do not have to use pthread_create or something else for
guiding optimization of atomics).

Where appropriate, the remaining implementations should have fast
paths which avoid atomics.  The old approach, where the libpthread
implementations do not have fast paths and the libc implementations do
not use atomics, fail to optimize the rather common case of
single-threaded processes that load libpthread via a library
dependency.  We also have subtle bugs because process-shared mutexes
cannot be locked and unlocked properly unless the program is linked
against libpthread, but nothing actually enforces that if the mutexes
are created by a different process.