Re: [PATCH] pthread_once hangs when init routine throws an exception [BZ #18435]

[Martin Sebor <msebor at redhat dot com>]

On 06/03/2015 01:14 PM, Rich Felker wrote:
> On Wed, Jun 03, 2015 at 01:03:47PM +0200, Torvald Riegel wrote:
> > On Mon, 2015-06-01 at 12:41 -0600, Martin Sebor wrote:
> > > Beyond call_once, C++ 11 encourages implementations to
> > > provide a member function called native_handle() that
> > > returns a reference to the underlying native object.
> > > libstdc++ mutex (and other classes) expose this member
> > > function to provide interoperability with pthreads. As
> > > a result, reimplementing libstdc++ independently of libc
> > > is impossible without losing such interoperability and
> > > without breaking compatibility with existing code.
> >
> > Note that the interoperability is also a dependency.  I think it's
> > actually better for libstdc++ to not make an ABI guarantee that
> > native_handle() returns a pointer to a PThreads entity;  this way, we do
> > have the freedom to improve libstdc++ independently of glibc and more
> > importantly of POSIX.
> > I don't know for sure whether Jonathan has applied the change already,
> > but IIRC, we agreed that native_handle() should return void*.
>
> I'm strongly in favor of having the underlying implementations be
> opaque and not guaranteeing pthread.

As the risk of continuing to diverge from the main topic of
this thread I think it might be worth clarifying this point.

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).

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.

Clang's libc++ does the same thing, as does the Visual C++
standard library (which exposes the OS HANDLE (void*) as its
native_handle_type).

Martin