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: Florian Weimer <fw at deneb dot enyo dot de>
- To: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, "Ben Maurer" <bmaurer at fb dot com>, libc-alpha at sourceware dot org
- Date: Tue, 17 Oct 2017 23:54:44 +0200
- 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>
* 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).
Does lttng-ust call these functions even if the application does not?
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.