"ulimit -s" has no effect?

[Andrew MacIntyre]

On Fri, 5 Feb 2004, Maciej Kalisiak wrote:

> I check that it is set by running "ulimit -s" without a numerical argument.
> The reported value is the one I have set, viz. much larger than the default of
> 8192 (kbytes).  This is the soft limit.  The hard limit is reported to be
> "unlimited".

I have no idea whether this affects Linux, but some pthreads
implementations hard code the stack size for the "primary" or
"initial" thread.

Python is built with thread support if possible (incl on Linux), but
without explicit use of the thread support Python code runs in the context
of the "primary" thread.

ISTR that RedHat, amongst others, changed thread implementations
relatively recently.

I know that there is/was a bug in the Python bug tracker on SF related
to this issue on Linux (symptom is test_sre dumping core) with Python
2.3.3.  This particular issue is sensitive to the version of gcc and
optimisation settings (& on Linux, whether the Python core is in a SO),
as newer releases/higher optimisation settings result in larger stack
frames.

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