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: Jonathan Wakely <jwakely at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Martin Sebor <msebor at redhat dot com>, Torvald Riegel <triegel at redhat dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 8 Jun 2015 12:23:59 +0100
- 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> <20150603210031 dot GN17573 at brightrain dot aerifal dot cx> <556F9272 dot 7050405 at redhat dot com> <20150604002122 dot GO17573 at brightrain dot aerifal dot cx>
On 03/06/15 20:21 -0400, Rich Felker wrote:
Is there anything non-conforming about making native_handle() just
return &this (i.e. considering the C++ object its own native
primitive)? That seems like the right solution.
As Martin said, it would be completely pointless. If you don't want to
allow access to the underlying primitive then you don't define
native_handle() at all.
Choice 3 is the utterly worst choice because once an application goes
down that path, there's no way to extricate the mess and make it
portable. If you need functionality that the C++ synchronization
objects don't provide then you need to make your own objects using
some other primitives, not make assumptions about how the C++ standard
library's primitives are implemented.
For portable code, yes. But native_handle() is meant for non-portable
uses.