This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] pthread_once hangs when init routine throws an exception [BZ #18435]
- From: Torvald Riegel <triegel at redhat dot com>
- To: Martin Sebor <msebor at redhat dot com>
- Cc: Rich Felker <dalias at libc dot org>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>, Jonathan Wakely <jwakely at redhat dot com>
- Date: Thu, 04 Jun 2015 09:51:51 +0200
- Subject: Re: [PATCH] pthread_once hangs when init routine throws an exception [BZ #18435]
- Authentication-results: sourceware.org; auth=none
- References: <556B7F10 dot 40209 at redhat dot com> <556C31DE dot 4020803 at arm dot com> <556CA772 dot 2060207 at redhat dot com> <1433329427 dot 21461 dot 101 dot camel at triegel dot csb> <20150603191444 dot GM17573 at brightrain dot aerifal dot cx> <556F6012 dot 6090502 at redhat dot com>
On Wed, 2015-06-03 at 14:14 -0600, Martin Sebor wrote:
> The sole purpose of the native_handle() function (whatever
> its return type may be) is to make it possible for components
> such as libraries to operate on the same mutex or thread object
> using the pthreads (or other "native") API as C++ programs that
> create and manipulate the objects using the C++ APIs and use
> the libraries. (I.e., the purpose is not just to expose some
> sort of a unique id for the object).
I think everyone of us is aware of that.
That can be useful in some cases, but it is really constraining in
others. It essentially ties the implementation to two APIs and ABIs.
We are giving out access to implementation details. It also ties
libstdc++ to two standards bodies.
The problem with mutexes in particular is that POSIX and C++11 mutexes
do *not* have exactly the same semantics. If POSIX should, wrongly so
IMO, insist on requiring successful mutex operations to have the effect
of a full barrier, then we will have to run with a different C++
implementation because we don't want to have this overhead for C++ too.
We could alternatively add a C++ mode as a new mutex kind (ie, a glibc
extension) and return mutexes of this kind, but that wouldn't be
compatible with old code either.
Therefore, I think giving out a void* with no strings attached, or not
supporting native_handle at all, are the right solutions so we don't end
up in a situation in which we can't fix or improve something without
both standards moving in the same direction.
> Since libstdc++ is already implemented in terms of pthreads
> and exposes the underlying pthreads types via native_handle
> (with all the ABI/API ramifications), I suspect there's
> little chance that the underlying implementation can change.
We wanted to change to void* with GCC-5, but missed that boat
unfortunately. We can document that we don't give ABI/API guarantees
for it, but this would be much clearer to users if this would return
void* I believe.