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: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>, Rich Felker <dalias at libc dot org>
- Cc: Martin Sebor <msebor at redhat dot com>, Torvald Riegel <triegel at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 08 Jun 2015 14:45:10 +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> <20150608112359 dot GU12728 at redhat dot com>
On 08/06/15 12:23, Jonathan Wakely wrote:
> 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.
does libstdc++ want to allow access to the underlying primitives?
ie. is it documented that the types are mapped to pthread types
and how to use them safely?
>> 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.
may be my idea about redoing the synchronization primitives in libstdc++
does not work, but there can be other reasons for libstdc++ to have
its semantics detached from the pthread api. allowing user code to use
pthread primitives behind the back of libstdc++ sounds problematic even
for 'non-portable' code.
i tried to dig up the rationale for native_handle but it seems early c++0x
documents already had it, presumably copied from boost::thread. i guess
it's too late to fix this now..
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2184.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2285.html
http://www.boost.org/doc/libs/1_58_0/doc/html/thread/thread_management.html#thread.thread_management.tutorial.native_in