(L) Prelim RFR: 8132510: Replace ThreadLocalStorage with compiler/language-based thread-local variables
Andrew Haley
aph at redhat.com
Wed Nov 11 10:56:43 UTC 2015
On 09/11/15 23:55, David Holmes wrote:
> On 9/11/2015 8:54 AM, David Holmes wrote:
>
> Just to keep my thinking straight on this, the problem only exists for
> threads that existed before the JVM was loaded. All threads allocated
> after that will have space for all the TLS variables allocated directly.
> So the problem scenario is:
>
> - external process with existing threads loads the JVM
> - existing thread is executing critical library function eg malloc, when
> it takes a process-directed signal.
> - JVM signal handler runs and accesses _thr_current which triggers
> dynamic TLS allocation
Why not simply use pthread_* thread-local storage, but only in the
signal handler? That would avoid the (fairly unlikely) race
condition, at very little cost. Sure, we'd have to use
pthread_setspecific() when attaching a thread, but that's no big deal.
Andrew.
More information about the porters-dev
mailing list