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

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

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.

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)

>> so using "in_signal_handler_context()" is not a valid
>> way to verify the as-safety interface contract.
>>
>>> that is, I want a `in_signal_handler_context()' utility that can be
>>> used as this:
>>>
>>> int mylibfunc( void ) {
>>>     if( in_signal_handler_context() ) { return(-1) }
>>>     // rest of function goes here
>>>     return( 0 );
>>> }
>>>
>>>
>>> Yubin
>>>
>>