This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]

Re: thread-local data access

To: Jakub Jelinek <jakub at redhat dot com>
Subject: Re: thread-local data access
From: Ulrich Drepper <drepper at redhat dot com>
Date: 27 Sep 2000 07:45:13 -0700
Cc: GNU libc hacker <libc-hacker at sourceware dot cygnus dot com>
References: <m37l7y9zih.fsf@otr.mynet.cygnus.com><20000927094308.B968@sunsite.ms.mff.cuni.cz>
Reply-To: drepper at cygnus dot com (Ulrich Drepper)

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.  Inlining these computations is a problem since
it would mean you cannot set the stack address (and size) yourself
anymore.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Follow-Ups:
- Re: thread-local data access
  - From: Jakub Jelinek

References:
- thread-local data access
  - From: Ulrich Drepper
- Re: thread-local data access
  - From: Jakub Jelinek

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]