On 15/08/17 16:47, Richard Biener wrote:
> On Tue, Aug 15, 2017 at 5:21 PM, Ron <r...@bitbabbler.org> wrote:
>> Is changing the cancellation state really an expensive operation?
>> Moreso than the checking which I assume already needs to be done for
>> noexcept to trap errant exceptions?
>
> The noexcept checking only needs to happen if an exception is thrown
> while the pthread cancel state needs to be adjusted whenever we are
> about to enter/exit such function.
>
>> If it really is, I guess we could also have an attribute which declares
>> a stronger guarantee than noexcept, to claim there are no cancellation
>> points in that scope, if people have something in a hot path where a few
>> cycles really matter to them and this protection is not actually needed.
>> Which could also be an automatic optimisation if the compiler is able to
>> prove there are no cancellation points?
>
> I guess that's possible.
>
> I suppose prototyping this would be wrapping all noexcept calls in
>
> try { pthread_setcancelstate (PTHREAD_CANCEL_DISABLE, &old); call
> (); } finally { pthread_setcancelstate (old, &old); }
>
i think changing the state this way is only valid if call
itself does not change the state, which we don't know.
