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: Andi Kleen <andi at firstfloor dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, 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: Thu, 20 Jun 2013 22:55:12 +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>
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)
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.
I believe such a change would make a my project worthless.
It would also make it very dubious to even have a "testing release"
as very few people would test anything for elision on.
If every program has to be changed we don't need to change glibc,
we could just use wrappers.
I also believe that "deadlock requirement" is a red hering. Everyone
who has a deadlock in their programs has a bug, not a "requirement".
Besides it will still deadlock eventually with my code.
I'm frankly mystified why anyone can even describe that as a
requirement.
> 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".
Anything that breaks binary compatibility or requires source code
changes in lots of programs is not "right for the project".
> But it seems to me that currently, we don't have consensus on your
> patches as they stand today; see Roland's requirements and my comments,
> for example. So, why can't we just go forward with what we hopefully
> could agree on, and deal with everything else later as soon as we have
> consensus?
Because crippling it so much makes it worthless for me (and I
believe for the glibc project and practically all of its users too).
No testing coverage, no easy use, no elision, just
lots of wasted work for everyone.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.