Re: thread-local data access

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Sep 26, 2000 at 10:26:14PM -0700, Ulrich Drepper wrote:
> We slowly have to think about the platforms which do not yet have
> thread-local data access through anything but the POSIX API.  This
> will be a problem since there are at least two changes coming up which
> require fast access the thread-local data.
> 
> The situation from my perspective is as follows:
> 
>  - x86:   %gs register, fast enough
>  - SPARC: dedicated thread register
>  - IA-64: likewise
>  - Alpha: PAL call, fast enough (according to rth)
> 
> What about the other architectures?  I guess m68k is not really that
> important anymore.  More of a problem for me are Arm, MIPS, and PPC.
> Also, do the people who designed the ABI for PA, SH, and S390 thought
> about this?

Thinking about it, wouldn't be better to just make the other arches slower
(e.g. by managing a global array of pointers to thread-local data indexed by
say [STACK_POINTER >> 16] (provided that we make sure that no two thread
stacks share the same 64K page))?
I know two memory accesses (and perhaps some cache misses) plus some math
will slow things down, on the other side I think it would be far worse if
programs won't be portable accross the architectures.
A threaded program could mmap (...PROT_NONE...) the 64K*sizeof(void *) array first
and then as the various stacks are created/destroyed, they would be
mmaped/munmaped as needed and filled with thread local pointers.

	Jakub