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: 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>, andi <andi at firstfloor dot org>
- Date: Thu, 20 Jun 2013 16:09:34 +0200
- Subject: Re: Update on freeze status of glibc 2.18?
- References: <51B65DE4 dot 4010107 at redhat dot com> <20130610231903 dot D9C602C09B at topped-with-meat dot com> <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>
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.
As I explained earlier even with elision there will be eventually
deadlocks for such programs, just not all the time.
So the "deadlock requirement" is mostly followed.
I think the disadvantages (disabling elision for all programs)
totally outweight the advantages (do something that is unlikely
to affect any real program)
How many programs do you have deadlocking and it's not a bug?
>From my point (and why I did this glibc elision project) the main
advantage of enabling elision in pthread is working with existing
programs and binaries. If that is broken, and every application
would have to be manually modified, the value for me is gone.
The point of releasing it to users for testing would be also moot because
the testing coverage would be very limited if it's not enabled.
If everything would need to be modified it alo doesn't make a lot of sense
to use pthread locks at all, but a more modern optimized and less overhead
locking interface.
But working with existing code bases and binaries is important.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.