> Yes, I've tried increasing the stack size. I think it is a platform
> specific problem for threads on FreeBSD/AMD64. Regardless of how large
> I make the stack, or how low I set the recursionlimit, python 2.3.4
> cannot complete test_re.py sucessfully on this platform.
FYI, the sys module's recursion limit only kicks in when Python
functions are calling Python functions. The re engine is coded
entirely in C, and recursions at the C level "don't count" toward the
sys module's recursion limit. IOW, only the stack size is relevant
for test_re in 2.3.4.
> I've tried bringing it up on the FreeBSD lists, but not got much of a
> response. Python 2.4a3 must do *something* different with threads, as
> it can complete test_re.py on the same platform.
test_re is probably a red herring here: starting with 2.4a1, Python's
re C implementation became *far* less recursive than prior
implementations. IOW, running test_re under 2.4 is a very different
(and much easier on the stack) thing than running test_re under 2.3.
So looking at test_re alone doesn't really imply anything about
The biggest stack hog in 2.4's test suite is the new test_compiler,
but it takes so long it only runs a subset by default. Pass "-u all
test_compiler" to regrtest.py to run the whole thing. If that passes
(== no output other than "1 test OK.")-- and it should --that's a
severe test of both the C stack and sys's recursion limit.
> I've tried backporting over thread_pthread.py from 2.4a3, but that doesn't do it. I
> think there may be extra defines set in the Makefile or configure.
Possibly, but I'm not optimistic about that line. That test_re failed
in 2.3.4 said you have "stack problems". That test_re passed in 2.4
just says that 2.4's re implementation doesn't stress the stack
anymore. But (the full) test_compiler does, so I'm betting that blows
up under 2.4 for you.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -