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

[Yubin Ruan <ablacktshirt at gmail dot com>]

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.

Yubin

> 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
>>
>