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


On Wed, Sep 27, 2000 at 08:16:07AM -0700, Ulrich Drepper wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > 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
> > }
> 
> You will need a 256k array for this.  We had to make the decision for
> the thread library and decided not to do it that way.

Yes, you need 256k array, but you don't need to populate it fully, usually
stacks don't take all the process virtual memory, usually just a small
fraction.

> 
> 
> Also, some applications allocate really small stacks for the threads
> (if it's known they don't need much) like this:
> 
>   char stacks[N][4096];
>   pthread_attr_t attr[N];
> 
>   for (n = ...)
>     pthread_attr_setstack (&attr[n], stacks[n], 4096);
> 
> You cannot safely assume that you have 64 for your own.

Ok, fine, but we could assume at least PTHREAD_STACK_MIN, provided that we
require on those architectures stacks to be aligned to PTHREAD_STACK_MIN
bytes.

	Jakub

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