Date: Mon, 26 May 2003 21:17:00 +1000 (EST) From: Andrew MacIntyre <andymac@bullseye.apana.org.au> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: alane@freebsd.org Subject: Re: setting stacksize in "initial" thread (pthreads, 4.8R) Message-ID: <20030526204036.D58689@bullseye.apana.org.au> In-Reply-To: <Pine.GSO.4.10.10305252329450.14009-100000@pcnet1.pcnet.com> References: <Pine.GSO.4.10.10305252329450.14009-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 25 May 2003, Daniel Eischen wrote:
> On Mon, 26 May 2003, Andrew MacIntyre wrote:
>
> > 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.
>
> How do you know it is the main thread stack and not a different
> thread stack that is getting exceeded? By default, threads
> other than main get a 64K stack, and this is totally configurable
> by the application.
Activating threads in Python requires importing either of the threads
support modules (theres a high level module & a low level module). The
regex regression test doesn't import either threads module.
Neither module supports setting the thread stack size from Python code.
Python by default uses the system's default thread stack size, but this
can be overridden at compile time. I've tried bumping the thread stack
size up from the default to 1MB with no effect.
Also, the recursive routine takes 3 arguments (2 pointers + 1 int, ie 12
bytes), and has at least 36 bytes worth of local variables. Failing with
~8100 levels of recursion means a minimum of ~380kB of stack consumption,
not including overhead (frame pointer, registers pushed to the stack,
etc), ie lots more than the default thread stack size.
The routine in question can easily support a stack exhaustion check on
each iteration, rather than relying on hard coded limits. Its just a
matter of knowing how to do the check, and how expensive it is. Even
moderately expensive could be more attactive than tempting bus errors.
Regards,
Andrew.
--
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370
andymac@pcug.org.au (alt) | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030526204036.D58689>