Re: libpthread removal project

[Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>]

On 07/10/2019 14:18, 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.

i don't think the memory usage should be worse.

ideally most of libpthread is shareable rodata/text
and there will be at least something on the system
that depends on libpthread so all of that is in
memory anyway.

it seems currently the largest non-sharable part
of libpthread are relocs + got entries and dynamic
section some of which you can save if you move
it into libc.so.