Re: TLS, 2015 edition

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 30 Mar 2015, Stan Shebs wrote:

> Through a series of unfortunate events (starting with an infinite loop
> in an obscure Java test) I seem to have inherited the async-safe TLS
> problem.
> 
> >From what I can tell, there has not been much discussion following the
> patch reversion during 2.19's release process, aside from the proposal
> for a thread properties API:
> 
>     https://sourceware.org/ml/libc-alpha/2014-04/msg00313.html
> 
> So where are things at now?  From the extant discussion, I gather that
> there were some fundamental philosophical differences, and not even
> much meta-consensus on what consensus might look like.  :-)  Has
> anybody spent any time since then, thinking about this?

So far as there is any consensus, it's that lazy TLS allocation should not 
be the default for new binaries (that is, for newly linked calls to 
dlopen), although backwards compatibility for existing binaries may 
require symbol versioning for dlopen so that existing calls get lazy TLS 
allocation, and there may be uses for a new RTLD_LAZY_TLS that newly 
linked calls to dlopen can use to get lazy TLS allocation.

That is, what should be implemented as the proper fix is for all required 
memory to be allocated at dlopen (or pthread_create, as applicable) time.  
If anything further is required on the first use of a TLS variable (e.g. 
to allocate particular memory for that particular variable, from a 
sufficiently-large pool allocated at dlopen / pthread_create time), it 
should consist of async-safe atomic operations.

The approach of signal-safe allocators is a dead end.

-- 
Joseph S. Myers
joseph@codesourcery.com