[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Small stack size with libpthread?
From: |
Stephan Bergmann |
Subject: |
Re: Small stack size with libpthread? |
Date: |
Thu, 26 Jun 2003 09:27:01 +0200 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 |
Hi Wolfram.
Thanks a lot for your very detailed response. Some comments/questions
inline.
Hi,
In glibc-2.3.2/glibc-linuxthreads-2.3.2, code in pthread.c calls
setrlimit(RLIMIT_STACK, ...) with a soft limit of
max_stack = STACK_SIZE - __getpagesize();
(resulting in max_stack a little below 2MB with my Linux constellation.)
This code is executed at the start of a -lpthread linked program, and
cuts the stack size for the program's main thread. I have two questions
about this:
1 Why is max_stack a hard value, that does not take into account the
stacksize limit set by the user?
First, please note that this applies only to the case when
FLOATING_STACKS is not set in LinuxThreads. On many modern
systems/kernels, FLOATING_STACKS will be set and the following is a
moot point.
Is there some link explaining how FLOATING_STACKS works, and which Linux
kernels are currently using it? (From what I saw a test program on my
Suse 8.2 box behave, I concluded that the non-FLOATING_STACKS code in
pthread.c was executed.)
2 Why is there a call to setrlimit at all? I don't know the
implementation details, but I would assume that setrlimit(RLIMIT_STACK,
...) only controls the size of the main thread's stack. Why is it
changed? [I would also assume that calling setrlimit(RLIMIT_STACK, ...)
can have only limited effect when a program is already executing, e.g.,
it should not enlarge the stack into already used address space, and it
should not shrink the stack smaller than the current value of the stack
pointer. But some tests show that the size of the main thread's stack
is indeed cut by that call from pthread.c during initialization.]
AFAICS, the stack size was hardcoded in order to have enough address
space for the thread stacks, which are allocated starting immediately
below the main thread's stack. It seemed natural to limit the main
stack to the same size as the other threads' (however there was a
factor of 2 which wasn't properly accounted for in the rlimit call).
I see.
Anyway, I agree the fixed setrlimit() is _not_ necessary for the main
thread and while LinuxThreads has many design limitations, this is not
one of them. I append a patch for LinuxThreads which should give you
much more stack space (at most 128MB though) for the main thread, in
case the limit is set appropriately.
Thanks a lot for your efforts. Unfortunately, we would need this fix
for 'unknown' outside users using OpenOffice.org Basic, not so much
inhouse, so that it would probably be of not much help to try and get
this patch into glibc and wait that it is adopted by all the users out
there. But thanks anyway.
Since LinuxThreads is on its way of being phased out, I don't know
whether the patch will be accepted in glibc.
Again, any links for what will replace LinuxThreads (and when)?
I am asking this because we have a program component (the OpenOffice.org
Basic interpreter) that runs in a multithreaded program, but is
guaranteed to only ever run on the main thread, and can consume huge
amounts of stack space. The easiest fix seemed to increase the
stacksize limit in the shell script that starts the program, but that
turned out to have no effect...
Even better would be to use malloc() for large allocations..
More than true. It's just trying to (temporarily) overcome a problem in
a huge code base with the least effort...
Regards,
Wolfram.
Thanks,
-Stephan