Re: Proposal: Slow dynamic TLS for internal glibc use

[Florian Weimer <fweimer at redhat dot com>]

* Eric Rannaud:

> On Tue, Oct 23, 2018 at 7:27 AM Florian Weimer <fweimer@redhat.com> wrote:
>> Yes, the difference is observable to programs due to the way the
>> standard is written. I think there was a general confusion about thread
>> safety vs. state sharing when threading was introduced, and that
>> synchronization could make state sharing observable once data races are
>> avoided.
>>
>> > If I understand correctly the strtok implementation you are
>> > suggesting (see below), thread_a and thread_b would not be sharing
>> > state anymore, and thread_b would (hopefully) segfault (calling
>> > strtok(NULL, "\n") without a prior call with a non-null first
>> > argument).
>>
>> Correct. Some implementations already implement strtok with separate
>> states. At least for strtok, we could partially address that with
>> inheriting the state on pthread_create, but this seems excessive.
>>
>> But we need to be realistic and there are many, many libraries which use
>> both threads and strtok, and it's unlikely that we're going to switch
>> them to strtok_r, strsep or strcspn.
>
> 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?

On the other hand, there are many libraries which use both strtok and
pthread_create, and that's really not acceptable right now.

> 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.

Thanks,
Florian