This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libpthread removal project

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:
>   <>

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]