This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
RE: linuxthreads: why limit stack size to STACK_SIZE when not using FLOATING_STACK ?
- To: "Jakub Jelinek" <jakub at redhat dot com>
- Subject: RE: linuxthreads: why limit stack size to STACK_SIZE when not using FLOATING_STACK ?
- From: "Ken Whaley" <ken at believe dot com>
- Date: Wed, 8 Aug 2001 11:25:59 -0700
- Cc: <libc-alpha at sources dot redhat dot com>
> > If the user wants to supply a stack larger than STACK_SIZE
> > and getrlimit() will allow the larger size, is there some
> > reason not to allow it when not including useldt.h on x86?
>
> Yes. On IA-32 in that case there is no thread register (like %gs with
> --enable-kernel=2.4.0+ on i686, %g6 on sparc, %r13 on ia64, etc.),
> so the thread descriptor needs to be computed from current %esp value and
> that is done by (pthread_descr)(((unsigned long)sp |
> (STACK_SIZE-1))+1) - 1,
But when not using THREAD_SELF, and when the user supplies his
own stack, __pthread_nonstandard_stacks gets set to 1 in
pthread_allocate_stack(), which makes thread_self() return
__pthread_find_self() and you never get to the STACK_SIZE dependent
code you mention.
So here's the situation as far as I can see it:
1) thread_self() depends on STACK_SIZE only when the user never
supplies a stack. If the user supplies even a single stack,
linuxthreads will for the remaining lifetime of the process use
__pthread_find_self() and not the STACK_SIZE code.
2) if the user supplies a stack, linuxthreads limits it to STACK_SIZE
so that thread_self() will work.
But of course, the restriction in #2 is obviated by the code present
in #1, so why not remove the (seemingly...?) unnecessary
restriction in #2? Am I missing anything?
BTW I can't use THREAD_SELF because for various reasons I'm locked
into 2.2 kernels.
Ken