setting stacksize in "initial" thread (pthreads, 4.8R)

[Andrew MacIntyre]

On Sun, 25 May 2003, Daniel Eischen wrote:

> On Sun, 25 May 2003, Andrew MacIntyre wrote:
>
> > I have a situation with a Python interpreter built from Python
> > CVS sources that is hitting the stack limit for the "initial" thread
> > imposed by libc_r:  PTHREAD_STACK_INITIAL in
> > /usr/src/lib/libc_r/uthread/pthread_private.h is set to 1MB (0x100000).

{...}

> Is this something that is common to all python scripts, or is
> it just your own script(s) that is(are) getting caught.  It
> seems 1MB is an awful lot to be on the stack, and perhaps some
> things are better malloc'd.

The problem actually occurs with recursive matches in Python's regex
engine.  Python has a hardcoded regex recursion limit, which has trapped
ballistic matches before running out of the default stack.  However a
couple of recent fixes to the regex engine have increased stack
consumption, and the hard limit has to be lowered.

The failures are being exhibited by the Python regex engine regression
tests.

Compiler optimisation plays a role here:-
- gcc 2.95: -O3 hits the stack limit, -O2 doesn't;
- gcc 3.2.2: -Os is the only optimisation setting that doesn't hit the
  stack limit.

(these all with the default regex recursion depth).

I was hoping there was a way to avoid FreeBSD having a recursion limit
lower than any other OS in the presence of threads, but your response
indicates there isn't - at least using libc_r.

Using the Linuxthreads port instead of libc_r works fine.

--
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac at bullseye.apana.org.au  (pref) | Snail: PO Box 370
        andymac at pcug.org.au             (alt) |        Belconnen  ACT  2616
Web:    http://www.andymac.org/               |        Australia