This is the mail archive of the 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

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.


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