Re: determine whether code is running in a signal handler context

[Carlos O'Donell <carlos at redhat dot com>]

On 10/23/2017 03:01 AM, Szabolcs Nagy wrote:
> On 22/10/17 07:06, Carlos O'Donell wrote:
>> On 10/20/2017 10:48 AM, Szabolcs Nagy wrote:
>>> On 20/10/17 18:19, Carlos O'Donell wrote:
>>>> On 10/20/2017 04:31 AM, Szabolcs Nagy wrote:
>>>> The converse is true too, if such an API call says you are
>>>> *not* in a signal handler, you may always run AS-unsafe
>>>> code because you know you could not have interrupted
>>>> AS-unsafe code.
>>>>
>>>
>>> that is usually true but may be false: if the
>>> programmer thinks a call is as-safe when it isn't
>>> that can cause problems even if the call is not in
>>> a signal handler:
>>>
>>> int main()
>>> {
>>> register_as_unsafe_handler();
>>> call(); // ok if as-safe, not ok if as-unsafe
>>> mask_signals();
>>> }
>>
>> I don't understand this example.
>>
>> Could you expand on this please?
> 
> it means that as-unsafe code may interrupt the call.
> (so if call is as-safe then there is no problem,
> otherwise there is)

Understood. Thank you for the clarification.

> in practice this kind of design (where the signal handler
> is as-unsafe and the main code is as-safe) is very rare,
> but it is a valid design (e.g. think async-cancellation:
> the main code is as-safe, and the interrupting code is
> as-unsafe since it exits the thread running dtors etc).

I agree completely. It is a valid design.

In this case, the proposed API would force considerable added
complexity.

>>>> The API could still have its uses?
>>>>
>>>
>>> yes it may have uses, but if a library tries to use
>>> it for sanity checks, then the false positives will
>>> cause headaches when somebody tries to use the
>>> library correctly from a signal handler.
>>
>> The false positive being that you run AS-safe code only,
>> but you *could* have run AS-unsafe if you'd accurately
>> tracked what kind of context you interrupted?
>>
>> In that case I would not say or use the word "correct"
>> or "incorrect", since the code works, but it *might*
>> conservatively require you to run AS-safe only functions.
>> In that case it's a performance and algorithmic complexity
>> issue. It *is* correct because you never do anything that
>> is undefined according to the standard.
>>
> 
> ok, with the assumption that the library call is only
> required to be as-safe in signal handlers.

Yes.

>>> so it's a lot of complication for a not quite correct
>>> check whether as-unsafe libc api is async reentered.
>>
>> It is correct, but not precise.
>>
>>> (e.g. a correct check would be inc/dec of a tls
>>> counter in every as-unsafe libc api on entry/exit
>>> and checking the counter, the libc could do this
>>> without a public api change, may be possible to do
>>> as an ld_preload hack if somebody really cares..
>>> of course there are complications with callbacks
>>> and, calls that go back to libc via plt etc, but
>>> i think this can be made correct unlike the signal
>>> context check)
>>
>> s/correct/precise/g
> 
> ok.

Please forgive my pedantism. I want everyone reading this
thread in the future to understand that correct in this case
is about avoiding undefined behaviour e.g. interrupting an
AS-unsafe context and running more AS-unsafe code. Rather than
a performance/complexity issue where an API uses a heuristic
that causes you to be AS-safe more often than you should.

The implementation of the API we are talking about could choose
to ignore the less frequently used case of AS-safe program being
interrupted by an AS-unsafe handler, in order to simplify the
code required to implement the API. Otherwise, as you state,
you need to precisely track the context being interrupted.

I think we've probably hashed out this issue to its maximum
extent :-) Hopefully the original poster has had their question
answered.

-- 
Cheers,
Carlos.