This is the mail archive of the libc-alpha@sourceware.org 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 Sun, Oct 6, 2019 at 11:25 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> 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.

Agreed. The possible drawback is a higher increase in memory footprint, but I
also think the benefits in general usage described are large in the long term.


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