[RFC PATCH glibc] pthread_setspecific: Provide signal-safety across keys

[Mathieu Desnoyers]

----- On Oct 17, 2017, at 5:54 PM, Florian Weimer fw@deneb.enyo.de wrote:

> * Mathieu Desnoyers:
> 
>>  	  if (value == NULL)
>>  	    /* We don't have to do anything.  The value would in any case
>>  	       be NULL.  We can save the memory allocation.  */
>>  	    return 0;
>>  
>> +	  /* Ensure that pthread_setspecific and pthread_getspecific are
>> +             signal-safe when used on different keys.  */
>> +          sigfillset (&ss);
>> +          pthread_sigmask (SIG_BLOCK, &ss, &old_ss);
>> +          /* Read level2 again with signals disabled.  */
>> +          level2 = THREAD_GETMEM_NC (self, specific, idx1st);
>> +          if (level2 != NULL)
>> +            goto skip_resize;
>> +
>>  	  level2
>>  	    = (struct pthread_key_data *) calloc (PTHREAD_KEY_2NDLEVEL_SIZE,
>>  						  sizeof (*level2));
> 
> I don't see how this adds signal safety.  If the function is called
> from a signal handler, interrupting the malloc code, then this will
> still result in undefined behavior (heap corruption or deadlocks).

Good point, I should probably turn this calloc into a on-demand mmap
or such then.

> 
> Does lttng-ust call these functions even if the application does not?

Yes.

> Then you really need to switch to real thread-local variables with the
> intial-exec model, possibly with indirection through a thread-local
> pointer variable and on-demand allocation using mmap in case you do
> not want to have these allocations in every thread.

Actually, liburcu-bp, which is the library actually using
pthread_setspecific, does use a TLS pointer to a mmap'd region.

The __thread variable sits in a library shared object, so it's not
possible to use the initial-exec model. I work around this by touching
the object once in a library constructor before other threads are
launched. AFAIU, this takes care of performing the TLS lazy fixup.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com