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: Martin Sebor <msebor at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- 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, 03 Jun 2015 17:49:06 -0600
- 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>
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).
Martin