This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Update on freeze status of glibc 2.18?
- From: Torvald Riegel <triegel at redhat dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: Roland McGrath <roland at hack dot frob dot com>, "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Ryan Arnold <rsa at us dot ibm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Fri, 21 Jun 2013 00:01:23 +0200
- Subject: Re: Update on freeze status of glibc 2.18?
- References: <51B66222 dot 1040300 at redhat dot com> <20130614224427 dot 4B2532C077 at topped-with-meat dot com> <51BF3CF8 dot 1010901 at redhat dot com> <1371494971 dot 16968 dot 21574 dot camel at triegel dot csb> <20130617193649 dot 7B5872C08D at topped-with-meat dot com> <1371503900 dot 16968 dot 21902 dot camel at triegel dot csb> <20130619224234 dot 5AC132C10E at topped-with-meat dot com> <1371733830 dot 964 dot 1089 dot camel at triegel dot csb> <20130620140934 dot GZ6123 at two dot firstfloor dot org> <1371743530 dot 964 dot 1602 dot camel at triegel dot csb> <20130620205512 dot GD6123 at two dot firstfloor dot org>
On Thu, 2013-06-20 at 22:55 +0200, Andi Kleen wrote:
> On Thu, Jun 20, 2013 at 05:52:10PM +0200, Torvald Riegel wrote:
> > On Thu, 2013-06-20 at 16:09 +0200, Andi Kleen wrote:
> > > If you're looking for consensus, there's no consensus from me
> > > for the DEFAULT != NORMAL proposal. Please don't discuss
> > > it like there is. In fact I totally object to it.
> >
> > First of all, let's remind ourselves that DEFAULT != NORMAL does *not*
> > disallow anything that you proposed. It allows us to do just some parts
> > of what you proposed, but it doesn't prevent all the other parts. So
> > why do you object? Because it enables a possibility to do just parts of
> > what you proposed?
>
> I object to any changes that disallow elision for
>
> pthread_mutex_t foo = PTHREAD_MUTEX_INITIALIZER;
>
> or
>
> pthread_mutex_t foo;
> pthread_mutex_init(&foo, NULL);
>
> (depending on the default setting/configs of the library of course)
And it will not disallow elision for these cases. As Roland points out,
those default to the DEFAULT mutex type. That's also why in stage 1) of
my suggestions for how to split up your patches so that we can commit
what we have consensus on (see my reply to v12), we would do the
DEFAULT != NORMAL enum value split *and* modify the initializers to use
the *new* enum value for DEFAULT.
> My project is about enabling transparent elision for the 90+% of programs using
> pthreads and I believe they primarily use these mutex modes, not "DEFAULT"
> or anything else.
And that's my goal too, and I believe Carlos' as well. But these
(initialization) modes *are* DEFAULT.
Not violating any POSIX semantics allows us to support exactly this use
case because then, one can enable elision widely if there's no risk of
breaking correct programs (as specified by POSIX). If we would have the
risk, we just couldn't throw elision at the 90%.
> > If everything you proposed is right for the project, we can still do it.
>
> I'm biased, but I believe wide spread use of elision with binary
> compatibility is "right for the project".
And we don't agree on this goal. But we have to consider more
constraints, that's why we have a different opinion on how to reach it.
> Anything that breaks binary compatibility or requires source code
> changes in lots of programs is not "right for the project".
The DEFAULT != NORMAL change wouldn't break ABI compatibility (but you
would need to compile against a new glibc to make use of elision), and
it would require any source code changes. We agree on these goals too.