Re: libpthread removal project

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

On 07/10/2019 15:19, Szabolcs Nagy wrote:
> 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.

hm i missed the large .bss for pthread_keys

   815: 000000000002b2f0 16384 OBJECT  LOCAL  DEFAULT   26 __GI___pthread_keys

i guess that's non-shareable, so it is committed
memory, but can be unallocated if it's unused.

if it's a concern it can be changed to use malloc.