From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72080 invoked by alias); 3 Jun 2015 20:14:15 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 72069 invoked by uid 89); 3 Jun 2015 20:14:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_20,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Message-ID: <556F6012.6090502@redhat.com> Date: Wed, 03 Jun 2015 20:24:00 -0000 From: Martin Sebor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Rich Felker , Torvald Riegel CC: Szabolcs Nagy , GNU C Library , Jonathan Wakely Subject: Re: [PATCH] pthread_once hangs when init routine throws an exception [BZ #18435] References: <556B7F10.40209@redhat.com> <556C31DE.4020803@arm.com> <556CA772.2060207@redhat.com> <1433329427.21461.101.camel@triegel.csb> <20150603191444.GM17573@brightrain.aerifal.cx> In-Reply-To: <20150603191444.GM17573@brightrain.aerifal.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg00115.txt.bz2 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