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


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]