This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Upcoming feature freeze vs. concurrency change
- From: Torvald Riegel <triegel at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, "Carlos O'Donell" <carlos at redhat dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- Date: Wed, 29 Jun 2016 20:04:31 +0200
- Subject: Re: Upcoming feature freeze vs. concurrency change
- Authentication-results: sourceware.org; auth=none
- References: <1467212290 dot 3700 dot 22 dot camel at localhost dot localdomain> <alpine dot DEB dot 2 dot 20 dot 1606291721100 dot 22371 at digraph dot polyomino dot org dot uk>
On Wed, 2016-06-29 at 17:23 +0000, Joseph Myers wrote:
> On Wed, 29 Jun 2016, Torvald Riegel wrote:
>
> > I have been working on a new, more scalable rwlock implementation. The
> > last information I have about the feature freeze is stating July 1st.
> > Is this still up to date? I believe I'll need a few more days to finish
> > the rwlock if all works well, but I won't make Jul 1st because I'm AFK
> > tomorrow till Sunday. Would this still be acceptable?
>
> What are you proposing regarding consequent effects on the release date?
> If we're not frozen for 1 July then I won't have ARM / MIPS /
> powerpc-nofpu testing started before late July.
My intent is not to move the overall schedule; it seemed that when this
was discussed, several people said that they would really like to have a
release schedule that does not slip.
Adding a few things slightly after the freeze might still be possible
without affecting the release date, which is why I asked (e.g., if
nobody would actually start testing right after the freeze for whatever
reason).
That said, the decision is still for the community to make.
The rwlock is not arch-specific and uses only 32b atomics, so as long as
we test on some weak memory archs, I believe starting to test later on a
few other archs might be fine.
The spinning in mutexes is entirely a performance optimization and
simple code. Choosing the right numbers is less so, but I'd restrict
that to x86 at first anyway, because I can test easily on this arch.
Regarding the condition variable, it would be nice if I could get a full
review soon (Florian has looked through the patch, but AFAIK he hasn't
reviewed the concurrency parts in detail). This would allow us to start
testing soon. Alternatively, I can commit it now, so that we start
testing soon, and we can revert it if anything should come up.