Re: Proposal: Slow dynamic TLS for internal glibc use

[Florian Weimer <fweimer at redhat dot com>]

* Eric Rannaud:

> Could anyone be relying on the de facto shared state across threads
> with the non-reentrant versions? While strtok, say, isn't thread-safe,
> it can be used safely with external synchronization. It would be a
> little odd, but you could imagine the following being in use:

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.

Thanks,
Florian