This is the mail archive of the mailing list for the glibc project.

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

RE: linuxthreads: why limit stack size to STACK_SIZE when not using FLOATING_STACK ?

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


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