This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Proposal: Slow dynamic TLS for internal glibc use
On October 23, 2018 10:10:59 AM PDT, Florian Weimer <fweimer@redhat.com> wrote:
>> I think I would argue that the glibc should take a conservative
>> approach here and aim to limit observable changes.
>
>Have you seen an application which will be broken by this, maybe by
>porting it to Solaris?
No I do not. I'm only guessing that someone somewhere wrote a wrapper with locking around one of these functions, to support targets that do not have the reentrant variant. And instead of using the reentrant variant if available, chose to use the same code everywhere.
A few releases of glibc could contain instrumentation to detect use from multiple threads (keeping track of which thread IDs call your new functions with a given key) and warn about it, for cases where a change in observable behavior is possible (e.g. strtok, but not gethostbyname I think).
But maybe all this concern is overblown.
>> You could use your approach to allocate state and also allocate a
>> mutex on the heap, from a single thread static root: the function
>> state would then be shared among threads (as now), but thread-safe by
>> default protected by the mutex (as in my strtok draft
>implementation).
>
>That doesn't provide thread safety in any useful sense. The data race
>inside the library would be gone, but concurrent use would still not
>deliver consistent results.
Yes indeed.