Re: Small stack size with libpthread?

[Stephan Bergmann]

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