Re: libpthread removal project

[Carlos O'Donell <carlos at redhat dot com>]

On 10/4/19 5:57 AM, Florian Weimer wrote:
> One of my long-term goals is to remove libpthread and move everything
> into libc.  The remaining library will just be stub, and maybe contain
> some compatibility data symbols (if we have any by then).
> 
> My motivation for this is that we continue to have problems with
> underlinking and symbol versioning.  For example, users forget to link
> against librt and therefore get the compat definition of timer_create at
> run time.  Another example is libstdc++, which uses an unversioned
> reference to pthread_create, which is bound to the compat definition of
> pthread_create.  (This only works because libstdc++ doesn't pass any
> thread attributes.)
> 
> Some libraries (including libstdc++) use weak symbol references to
> detect the presence of libpthread.  If libpthread has not been loaded,
> they assume that they do not have to use atomics for updating counters
> etc.  After libpthread removal, this optimization no longer works.  This
> is why I plan to add the __libc_single_threaded variable as a
> replacement, which will continue to work for detecting single-threaded
> processes once pthread_create or pthread_key_create are always
> available.  (The not-linking-against-libpthread optimization is already
> of decreased use today because a lot of single-threaded processes load
> the library indirectly, so I think .)
> 
> Previous discussion:
> 
>   <https://sourceware.org/ml/libc-alpha/2019-08/msg00295.html>

I think this is the right way forward and avoids a number of difficult
and nasty corner cases we get wrong. Like it or not threads are an integral
part of the implementation, and we should move in that direction.

-- 
Cheers,
Carlos.