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 12/17/2015 06:10 PM, 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.

No, I think it's more general than that.  But you can't set a constraint
handler, call a library function (in a different DSO), and have your
constraint handler called on failure.  But that doesn't work in general
anyway because the library might use the constraint handler in a
specific way to implement what it needs.  (The latter is the reason why
there is discussion about having more than one constraint handler per
process.)

> 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.

With the per-DSO model, you could still install a constraint handler
that wraps around the actual handler, after loading it from a
thread-local variable.  But I expect that few libraries will need this.

To clarify, the advantage of the per-DSO model is that you can call

  set_constraint_handler_s (abort_handler_s);

from a DSO constructor (because the default handler may not actually
abort the process), and afterwards, call

  strcpy_s(buf, sizeof (buf), source);

and get process termination if the constraint is violated.

Under the per-thread model, you'd have to use:

 constraint_handler_t old = set_constraint_handler_s (abort_handler_s);
 strcpy_s(buf, sizeof (buf), source);
 set_constraint_handler_s (old);

I can't see anyone writing code like this.  The Annex K functions are
there to retrofit legacy code, and now you have to introduce additional
cleanup paths, which is not a strictly local change.  It's just not
worth it.

> 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.

Understood, thanks.

Florian


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