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

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

On 10/20/2017 04:31 AM, Szabolcs Nagy wrote:
> On 20/10/17 12:23, Yubin Ruan wrote:
>> Thanks Szabolcs,
>>
>> 2017-10-20 18:32 GMT+08:00 Szabolcs Nagy <szabolcs.nagy@arm.com>:
>>> On 18/10/17 15:18, Yubin Ruan wrote:
>>>> Hi,
>>>>
>>>> I am writing to see if this is any util functions in libc that can
>>>> help to determine it is currently running in a signal.
>>>>
>>>> I wrote some library and provide a function which will be used in many
>>>> client code. However this function is not async-signal safe (it calls
>>>> malloc(3)) so when it is called, I want to detect whether it is
>>>> currently running in a signal handler. If it is, I can avoid calling
>>>> those not-async-signal-safe functions which might cause deadlock.
>>>>
>>>
>>> note that in posix as-safety is symmetric between the
>>> interrupted code and interrupt handler: if any of the
>>> interrupt and interrupt handler is as-safe then the
>>> behaviour is well defined.
>>>
>>> so calling non-as-safe code in an asynchronous signal
>>> handler is perfectly fine if the interrupted code is
>>> as-safe.
>>>
>>> there are synchronous signals too, i.e. raise(sig),
>>> and then the signal handler runs in well-defined state
>>> (one can use signal masks to make sure a signal handler
>>> only runs in such state)
>>
>> Actually I think the point is that that piece of code should not run
>> in a signal handler. That have nothing to do with sync-signal or
>> async-signal code, because in both case we might encounter deadlock.
>> From this perspective, that `in_signal_handler_context()' make sense
>> to me.
> 
> there is no deadlock, malloc is safe to call in a signal
> handler in posix if the signal interrupts as-safe code.
> 
> this entire mailing list thread assumes that only as-safe
> code may run in a signal handler and that is wrong.

Correct.

I didn't want to go down more complex scenarios.

> your api proposal does not make sense in a posix libc.
> (which explains why it does not exists)
> 
> (the libc startup code may raise a reserved realtime
> signal and make all programs run from a signal handler,
> it would be a posix conform implementation and your
> 'in_signal_handler_context' would be always true)

Conservatively, if you see you are in a signal handler, 
and always run AS-safe code, you are always safe.

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.

The API could still have its uses?

-- 
Cheers,
Carlos.