libpthread removal in 2.34

libpthread removal in 2.34

[Florian Weimer]

I've looked at what it would take to complete the libpthread removal for
the upcoming release.  Taking things like vacations into account, we
would have to move around fifteen functions per week, to be done by the
end of the development week.

From a coding perspective, this isn't much of a problem, even though
it's a fairly large patch set.  (I would keep splitting it up on a
per-file basis, to aid bisection in case there's a regression.)
Unfortunately, there is limited global review activity on libc-alpha
these days.  So I'm not sure if we can make through the entire set of
functions in time for the release.

Due to its nature, this change only benefits users once it is complete,
so that the issues related to late loading of libpthread and
GLIBC_PRIVATE internal ABI dependencies are gone.  If it's not realistic
to get the entire change into the upcoming release, maybe I should focus
on something else, and just make sure that there is always a libpthread
symbol move patch available for review in case someone has some review
cycles to spare.  This way, there is going to a little bit of progress
in every release.

Thanks,
Florian

Re: libpthread removal in 2.34

[Carlos O'Donell]

On 3/11/21 6:26 AM, Florian Weimer via Libc-alpha wrote:
> I've looked at what it would take to complete the libpthread removal for
> the upcoming release.  Taking things like vacations into account, we
> would have to move around fifteen functions per week, to be done by the
> end of the development week.
> 
> From a coding perspective, this isn't much of a problem, even though
> it's a fairly large patch set.  (I would keep splitting it up on a
> per-file basis, to aid bisection in case there's a regression.)
> Unfortunately, there is limited global review activity on libc-alpha
> these days.  So I'm not sure if we can make through the entire set of
> functions in time for the release.
> 
> Due to its nature, this change only benefits users once it is complete,
> so that the issues related to late loading of libpthread and
> GLIBC_PRIVATE internal ABI dependencies are gone.  If it's not realistic
> to get the entire change into the upcoming release, maybe I should focus
> on something else, and just make sure that there is always a libpthread
> symbol move patch available for review in case someone has some review
> cycles to spare.  This way, there is going to a little bit of progress
> in every release.

It is possible for you to move 15 functions a week, but it would be under
assumed consensus and that we are all, including yourself, comfortable
with doing the move with minimal review. This seems a bit tricky because
we are not just moving code, but refactoring and removing duplicated systems
(like the unwinder changes).

There are only ~5-8 high level reviewers and their time is indeed in demand
both by their employers and by the community. Most of them attend the weekly
patch review meethings to attempt to make forward progress on patches.

However, as you've seen, if the patch is very detailed it will take a lot of
time to get review and make progress. That's just the nature of the position
of glibc in the total software stack. I expect some of the patches to move
and refactor libpthread would get stuck so we'd naturally fall behind and miss
the 2.34 deadline.

In summary:

- There are a number of outstanding issues we can probably fix this release:

  * 64-bit time_t

  * Atomic fixes for TLS and the dynamic loader

  * C.UTF-8 (implement shortcuts to avoid large locale)

  I think that the atomic fixes for TLS in the dynamic loader would be helped
  by your current experience fixing NODELETE and rewriting parts for glibc-hwcaps.
  $0.02.

- It would also be great to make some progress on libpthread removal such
  that the remaining work is doable in 2.35.

-- 
Cheers,
Carlos.

Re: libpthread removal in 2.34

[Adhemerval Zanella]

On 11/03/2021 11:26, Carlos O'Donell via Libc-alpha wrote:
> On 3/11/21 6:26 AM, Florian Weimer via Libc-alpha wrote:
>> I've looked at what it would take to complete the libpthread removal for
>> the upcoming release.  Taking things like vacations into account, we
>> would have to move around fifteen functions per week, to be done by the
>> end of the development week.
>>
>> From a coding perspective, this isn't much of a problem, even though
>> it's a fairly large patch set.  (I would keep splitting it up on a
>> per-file basis, to aid bisection in case there's a regression.)
>> Unfortunately, there is limited global review activity on libc-alpha
>> these days.  So I'm not sure if we can make through the entire set of
>> functions in time for the release.
>>
>> Due to its nature, this change only benefits users once it is complete,
>> so that the issues related to late loading of libpthread and
>> GLIBC_PRIVATE internal ABI dependencies are gone.  If it's not realistic
>> to get the entire change into the upcoming release, maybe I should focus
>> on something else, and just make sure that there is always a libpthread
>> symbol move patch available for review in case someone has some review
>> cycles to spare.  This way, there is going to a little bit of progress
>> in every release.
> 
> It is possible for you to move 15 functions a week, but it would be under
> assumed consensus and that we are all, including yourself, comfortable
> with doing the move with minimal review. This seems a bit tricky because
> we are not just moving code, but refactoring and removing duplicated systems
> (like the unwinder changes).
> 
> There are only ~5-8 high level reviewers and their time is indeed in demand
> both by their employers and by the community. Most of them attend the weekly
> patch review meethings to attempt to make forward progress on patches.
> 
> However, as you've seen, if the patch is very detailed it will take a lot of
> time to get review and make progress. That's just the nature of the position
> of glibc in the total software stack. I expect some of the patches to move
> and refactor libpthread would get stuck so we'd naturally fall behind and miss
> the 2.34 deadline.
> 
> In summary:
> 
> - There are a number of outstanding issues we can probably fix this release:
> 
>   * 64-bit time_t
> 
>   * Atomic fixes for TLS and the dynamic loader
> 
>   * C.UTF-8 (implement shortcuts to avoid large locale)
> 
>   I think that the atomic fixes for TLS in the dynamic loader would be helped
>   by your current experience fixing NODELETE and rewriting parts for glibc-hwcaps.
>   $0.02.
> 
> - It would also be great to make some progress on libpthread removal such
>   that the remaining work is doable in 2.35.
> 

I can help you on the libpthread removal project, if you want help on work
besides review you can lay out the missing interfaces and work work in
parallel.

Re: libpthread removal in 2.34

[Florian Weimer]

* Carlos O'Donell:

> However, as you've seen, if the patch is very detailed it will take a lot of
> time to get review and make progress. That's just the nature of the position
> of glibc in the total software stack. I expect some of the patches to move
> and refactor libpthread would get stuck so we'd naturally fall behind and miss
> the 2.34 deadline.
>
> In summary:
>
> - There are a number of outstanding issues we can probably fix this release:
>
>   * 64-bit time_t
>
>   * Atomic fixes for TLS and the dynamic loader
>
>   * C.UTF-8 (implement shortcuts to avoid large locale)
>
>   I think that the atomic fixes for TLS in the dynamic loader would be helped
>   by your current experience fixing NODELETE and rewriting parts for glibc-hwcaps.
>   $0.02.
>
> - It would also be great to make some progress on libpthread removal such
>   that the remaining work is doable in 2.35.

I'm not sure if you are trying to give a realistic assessment of the
situation or describing a desired outcome.  Do you think further
discussion is needed, or do you consider this settled (i.e., delay to
2.35 or some later version)?

Thanks,
Florian

Re: libpthread removal in 2.34

[Florian Weimer]

* Adhemerval Zanella:

> I can help you on the libpthread removal project, if you want help on work
> besides review you can lay out the missing interfaces and work work in
> parallel.

I think we should probably swap between reviews and writing patches.
Splitting up the work seems hard because of the Makefile and Versions
conflicts that are difficult to avoid.  I have an abilist merger, which
should at least help with incorporating symbol additions due to
unrelated glibc work.

I have a bunch of pending patches in Patchwork right now.  The next step
after that will be moving the cancellation implementation, then
mutex/condvar (probably in one big patch).  I had started on the
mutex/condvar step before, but ran into unwinding interactions (hence
the present series) and the private-futex issue.  All this should cut
down struct pthread_functions by quite a bit.

Removing the $(pthread-compat-wrappers) seems largely independent of
that.  These symbols sort separately in the Versions file, too.  If you
could work on that, it would definitely help.  I suggest to follow the
one-commit-per-file approach, in case we need to track down regressions.
(My present series already removes longjmp.)

Thanks,
Florian

Re: libpthread removal in 2.34

[Carlos O'Donell]

On 3/11/21 2:21 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> However, as you've seen, if the patch is very detailed it will take a lot of
>> time to get review and make progress. That's just the nature of the position
>> of glibc in the total software stack. I expect some of the patches to move
>> and refactor libpthread would get stuck so we'd naturally fall behind and miss
>> the 2.34 deadline.
>>
>> In summary:
>>
>> - There are a number of outstanding issues we can probably fix this release:
>>
>>   * 64-bit time_t
>>
>>   * Atomic fixes for TLS and the dynamic loader
>>
>>   * C.UTF-8 (implement shortcuts to avoid large locale)
>>
>>   I think that the atomic fixes for TLS in the dynamic loader would be helped
>>   by your current experience fixing NODELETE and rewriting parts for glibc-hwcaps.
>>   $0.02.
>>
>> - It would also be great to make some progress on libpthread removal such
>>   that the remaining work is doable in 2.35.
> 
> I'm not sure if you are trying to give a realistic assessment of the
> situation or describing a desired outcome.  Do you think further
> discussion is needed, or do you consider this settled (i.e., delay to
> 2.35 or some later version)?

Sorry, let me clarify my position a bit more.

tl;dr

I think we can remove libpthread in 2.34, but I think we need 1 developer to
help and 1 other reviewer to help and commit to doing it in 2.34.

Details:

(1) libpthread removal in 2.34.

- Requires 15 interfaces per week.
- Requires 1 dedicated developer to do the work.
  - You suggest we swap between reviews and work, but not parallelize
    due to the nature of teh work.
- Requires 1 dedicated reviewer.
  - I raised the question about accelerating reviews for work like this in Feb 2020:
    "Consensus on high-level objective of cleanup, refactor or rework patches."
    https://sourceware.org/pipermail/libc-alpha/2020-February/111118.html
  - Joseph suggested being more tactical with review:
    https://sourceware.org/pipermail/libc-alpha/2020-February/111140.html
    ~~~
    On Fri, 14 Feb 2020, Carlos O'Donell wrote:

    > Reviewers, like myself, should consider reviewing *less* when it is
    > clearly evident that additional review is not required?

    Yes.  Consider what it is about the patch that is relevant to review, 
    taking into account factors such as existing consensus for an overall 
    design, any relevant expertise of the patch submitter and the quality and 
    contents of the commit message and the testing described in that commit 
    message.
    ~~~

I think we can do the libpthread reviewing if we get:
- At least 2 developers to work together to distribute work.
- At least 2 dedicated reviewers to distribute work.

As of today I could setup a dedicated review slot for this work where I do
only this review, but I would want a backup reviewer so I could negotiate
time off and swapping reviews.

It looks like Adhemerval is willing to support the work, but I'd like another
reviewer to help me with the review load. Would you suggest anyone else?
My immediate suggestion is to ask Szabolcs or DJ for weekly review, both of
them have been through larger reviews and understand what needs reviewing.

(2) If we don't do libpthread removal in 2.34, I can suggest some other projects.

- See my notes in the original email.

-- 
Cheers,
Carlos.

Re: libpthread removal in 2.34

[Adhemerval Zanella]

On 11/03/2021 18:43, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> I can help you on the libpthread removal project, if you want help on work
>> besides review you can lay out the missing interfaces and work work in
>> parallel.
> 
> I think we should probably swap between reviews and writing patches.
> Splitting up the work seems hard because of the Makefile and Versions
> conflicts that are difficult to avoid.  I have an abilist merger, which
> should at least help with incorporating symbol additions due to
> unrelated glibc work.

I consider the merge issue a minor issue, since it is just a mechanical
step to actually fix it. 

> 
> I have a bunch of pending patches in Patchwork right now.  The next step
> after that will be moving the cancellation implementation, then
> mutex/condvar (probably in one big patch).  I had started on the
> mutex/condvar step before, but ran into unwinding interactions (hence
> the present series) and the private-futex issue.  All this should cut
> down struct pthread_functions by quite a bit.
> 
> Removing the $(pthread-compat-wrappers) seems largely independent of
> that.  These symbols sort separately in the Versions file, too.  If you
> could work on that, it would definitely help.  I suggest to follow the
> one-commit-per-file approach, in case we need to track down regressions.
> (My present series already removes longjmp.)

Alright, I will focus on $(pthread-compat-wrappers), I have been working
on some already and I will finish it then.