This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Another way to salvage Annex K and its constraint handler
- From: Rich Felker <dalias at libc dot org>
- To: Martin Sebor <msebor at gmail dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Martin Sebor <msebor at redhat dot com>
- Date: Thu, 17 Dec 2015 12:46:30 -0500
- Subject: Re: Another way to salvage Annex K and its constraint handler
- Authentication-results: sourceware.org; auth=none
- References: <564F3982 dot 5020504 at redhat dot com> <20151120193519 dot GY3818 at brightrain dot aerifal dot cx> <564F8650 dot 3080500 at redhat dot com> <20151120213551 dot GZ3818 at brightrain dot aerifal dot cx> <567288CC dot 7000604 at redhat dot com> <5672EC70 dot 9050700 at gmail dot com>
On Thu, Dec 17, 2015 at 10:10:08AM -0700, Martin Sebor wrote:
> >Anyway, I brought this up because I do think that for the Annex K
> >constraint handler, the per-DSO model is much more useful to programmers
> >than the per-thread model. With the per-DSO model, you don't usually
> >have to care about constraint handlers in a library at all. With the
> >per-thread model, you have to set and restore the constraint handler
> >around any use of Annex K functionality, which pretty much kills the
> >entire thing due to inconvenience.
>
> If I understand the per-DSO model you are suggesting, then it
> seems to me that it would work only for threads that run fully
> within the confines of a single DSO.
>
> Otherwise, distinct threads needing their own unique handler
> running code from or more libraries would still have no way
> to avoid stomping on each other's handlers.
>
> But that aside, even if the thread safety problem were solved,
> there are other (IMO more serious and more fundamental) issues
> with the annex that make its future uncertain. At the last
> WG14 meeting where we discussed N1969, in a poll of the
> participants, 9 out of 16 voted to remove Annex K from the next
> C standard. The rest said they would prefer to see it fixed or
> replaced with some better version. I would recommend to avoid
> investing too much effort into it until WG14 decides what to do
> with it.
I'm really glad to hear this, not just because Annex K is so bad, but
because it means the committee seems to be listening to concerns about
the kinds of problems that affect Annex K, particularly global state
and thread-safety/library-safety issues.
Rich