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] |
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] |