[lttng-dev] [PATCH 2/2] urcu: add notice to URCU_TLS() for it is not async-signal-safe

[Lai Jiangshan]

OK for me. Please do it.

On Thu, Aug 9, 2012 at 10:14 PM, Mathieu Desnoyers
<mathieu.desnoyers at efficios.com> wrote:
> * Lai Jiangshan (laijs at cn.fujitsu.com) wrote:
>> Signed-off-by: Lai Jiangshan <laijs at cn.fujitsu.com>
>> ---
>>  urcu/tls-compat.h |   14 ++++++++++++++
>>  1 files changed, 14 insertions(+), 0 deletions(-)
>>
>> diff --git a/urcu/tls-compat.h b/urcu/tls-compat.h
>> index 192a536..b7bf363 100644
>> --- a/urcu/tls-compat.h
>> +++ b/urcu/tls-compat.h
>> @@ -59,6 +59,20 @@ extern "C" {
>>
>>  #else /* #ifndef CONFIG_RCU_TLS */
>>
>> +/*
>> + * NOTE: URCU_TLS() is NOT async-signal-safe, you can't use it
>> + * inside any function which can be called from signal handler.
>> + *
>> + * But if pthread_getspecific() is async-signal-safe in your
>> + * platform, you can make URCU_TLS() async-signal-safe via:
>> + * ensuring the first call to URCU_TLS() of a given TLS variable of
>> + * all threads is called earliest from a non-signal handler function.
>> + *
>> + * Exmaple: In any thread, the first call of URCU_TLS(rcu_reader)
>> + * is called from rcu_register_thread(), so we can ensure all later
>> + * URCU_TLS(rcu_reader) in any thread is async-signal-safe.
>
> Hrm. We could also just block all signals within type *__tls_access_ ##
> name(void)  (in tls-compat.h) and make sure it is async-signal-safe I
> guess ? I would prefer that solution: it would make the code more robust
> for a rarely taken performance hit.
>
> Thoughts ?
>
> Thanks,
>
> Mathieu
>
>> + */
>> +
>>  # include <pthread.h>
>>
>>  struct urcu_tls {
>> --
>> 1.7.4.4
>>
>
> --
> Mathieu Desnoyers
> Operating System Efficiency R&D Consultant
> EfficiOS Inc.
> http://www.efficios.com