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: Rich Felker <dalias at libc dot org>
- To: Martin Sebor <msebor at redhat dot com>
- Cc: 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>, Jonathan Wakely <jwakely at redhat dot com>
- Date: Wed, 3 Jun 2015 20:21:22 -0400
- 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>
On Wed, Jun 03, 2015 at 05:49:06PM -0600, Martin Sebor wrote:
> >I understand the purpose here, but I also think it's a bad design and
> >not useful in portable code, which cannot make any assumptions about
> >the underlying system objects used by the C++ standard library of even
> >that "underlying" objects exist. I think the whole native_handle() API
> >just encourages non-portable constructs and implementation lock-in
> >that is harmful both to implementors (less freedom to improve) and
> >applications (trapped by implementation-specific assumptions).
>
> You're right, it does have that effect. It was a conscious
> design choice made by the authors of the C++ threads library.
> IIRC, some of the early design alternative included:
>
> 1) providing a rich set of functions that exposes the union of
> functionality of the underlying implementations; functions
> that don't have a native equivalent simply fail (the Rogue
> Wave Threads library does that)
>
> 2) providing a narrow interface (the C11 threads library takes
> this approach, though I don't think it precludes (3))
>
> 3) providing a narrow interface that exposes the common subset
> of functionality and give users a means to access the wrapped
> native objects
>
> The challenge with (1) is that it can be difficult to both
> specify and use portably because sometimes there are similar
> underlying APIs but with subtle differences.
>
> The problem with (2) is that it tends to be overly constraining
> for non-trivial uses.
>
> So C++ chose (3).
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.
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.
Rich