Re: thread-local storage: c front end and generic backend patch

[Richard Henderson <rth at redhat dot com>]

On Wed, May 22, 2002 at 01:41:51PM -0700, Mark Mitchell wrote:
> Is this really necessary?
> 
> The traditional approach (i.e., make structures containing data
> and then stuffing them into TLS) is workable, if slightly
> cumbersome.

This mechanism, or rather the run-time mechanism behind this,
is significantly faster.  It also solves a number of problems
with dynamic loading and wanting to share TLS data across DSO
boundaries.

> There's no definition of "thread" in the standard, so saying that
> these variables have the lifetime of "the thread" is probably
> insufficient.  "Prior to thread startup" is also a bit unclear; we
> don't know how to start a thread or what it means for it to be
> started.

This is intentionally vague.  Why would we mention pthread_create
here when the run-time might actually use some other thread library?

> Does the initialization take place in the parent or the
> child?  (That matters if, say, longjmps occur in the midst of the
> initializers.)

There are no run-time initializers for TLS data.  They are
specifically disallowed.

The run-time mechanism here is that TLS data is initialized via
block-copy from a PT_TLS ELF program segment.  So we can't have
constructors of any form.

I should track down a copy of C++98 so that I can make similar
standardese changes there.  That would have made this clearer
for you from the start.

> Is:
> 
>   extern __thread int i;
> 
>   extern int i;
> 
>   int i;
> 
> legal?  (Can you drop the "__thread" after you've said it once?  What
> if you don't say it the first time?)

Ooo good point.  I'd tend to want to force you to have it in the 
earliest declaration, but allow it to be dropped subsequently.

The rationale being that while

	extern int i;
	int foo() { return i; }
	static int i;

works, a similar case with __thread does not.  Further, one would
like to be able to do

	extern __thread int errno;

rather than the current best-effort in glibc:

	#define errno (*__errno_location ())

But old programs have a tendancy to redefine errno themselves
"just in case".

Alternately, most of these programs have been fixed over the last
few years because of the above define.  It might be sufficient to
have libc do

	extern __thread int errno;
	#define errno errno

since most of the fixes to the programs have been of the form

	#ifndef errno
	extern int errno
	#endif

Then we can reasonably enforce the restriction that every declaration
must contain the __thread specifier.

Thoughts?


r~