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: Roland McGrath <roland at hack dot frob dot com>
- Cc: Torvald Riegel <triegel at redhat 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: Fri, 21 Jun 2013 02:21:09 +0200
- Subject: Re: Update on freeze status of glibc 2.18?
- References: <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> <20130620230930 dot 6F21E2C135 at topped-with-meat dot com>
I appreciate all your efforts in designing this new ABI,
but I don't think it's necessary.
> That certainly seems very reasonable. Do you have a quick summary (or
> pointer to something) of how the C++11 mutex semantics differ from the
> POSIX mandate for PTHREAD_MUTEX_NORMAL?
AFAIK it doesn't have the deadlock specification bug.
I don't think it makes sense to back them with pthread mutexes at all --
even though that is currently done. The pthread mutexes have a lot
of fast path overhead for checking types etc. that C++ mutexes
could in principle avoid. So a high performance implementation would
not be based on the pthread code.
-Andi