This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Another way to salvage Annex K and its constraint handler


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]