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

[Yubin Ruan <ablacktshirt at gmail dot com>]

Thank you!

2017-10-23 22:30 GMT+08:00 Carlos O'Donell <carlos@redhat.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.

Actually I understand all those things you discussed and I know that
choosing to ignore the less frequently used case of AS-safe program
being interrupted by an AS-unsafe will be a lot easier and bring less
overhead. However, I just want to make the library code generic...

I am still working on it and will let you know if there are any advance.

Thanks,
Yubin