thread-local data access

[Jakub Jelinek]

On Wed, Sep 27, 2000 at 07:45:13AM -0700, Ulrich Drepper wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > 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))?
> 
> This is how finding thread local data (and also the thread descriptor)
> works in the moment.

No, at the moment if you don't have a dedicated thread register, you either
do __pthread_find_self which is a loop over threads or
return (pthread_descr)(((unsigned long)sp | (STACK_SIZE-1))+1) - 1;
With that you cannot obviously set the stack address and size yourself.

>  Inlining these computations is a problem since
> it would mean you cannot set the stack address (and size) yourself
> anymore.

But I was suggesting something like:

pthread_descr *__pthread_descr_array;

static inline pthread_descr thread_self (void)
{
#ifdef THREAD_SELF
  return THREAD_SELF;
#else
  char *sp = CURRENT_STACK_FRAME;
  return __pthread_descr_array[(unsigned long)sp >> 16];
#endif
}

where __pthread_descr_array would be created with (on 32bit arches):

__pthread_descr_array = mmap(NULL, (1 << 16) * sizeof(pthread_descr), PROT_NONE,
			     MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);

and later on mmaped/munmaped over with MAP_FIXED as needed during
pthread_initialize_manager, pthread_create and thread exits as well.

	Jakub