This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH glibc] pthread_setspecific: Provide signal-safety across keys
- From: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Ben Maurer <bmaurer at fb dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 17 Oct 2017 22:09:12 +0000 (UTC)
- Subject: Re: [RFC PATCH glibc] pthread_setspecific: Provide signal-safety across keys
- Authentication-results: sourceware.org; auth=none
- References: <20171017212919.741-1-mathieu.desnoyers@efficios.com> <87zi8pe8yj.fsf@mid.deneb.enyo.de>
----- 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