This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: libpthread removal project
On Mon, Oct 07, 2019 at 10:18:24AM -0300, Adhemerval Zanella wrote:
> 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.
Agreed as well. This is a good idea!
Christian