#62 ns/threads "stacksize = 0" avoids setting explicit stacksize

[Stephen]

This patch allows you to set stacksize=0 in the config
file to specify OS manged stack size.

If stacksize is set to zero or less (it has to be set,
it can't be left out), no stack size is specified when
creating threads, and in the case of Linux at least,
the stack will start off about 4k and grow automatically.

In all other respects behaviour is the same as before.
i.e. if you do not specify anything, stacksize
defaults to 64k; if you specify something more than
zero but less then 16k, it's rounded up to 16k.

[Stephen]

Patch to allow OS managed stack size

[Dossy Shiobara]

Logged In: YES
user_id=21885

Where do you see that not specifying the stack size on Linux
will allow Linux to dynamically grow the stack size? I see this
in the LinuxThreads FAQ:

http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html

E.5: Does LinuxThreads implement
pthread_attr_setstacksize() and pthread_attr_setstackaddr()?

These optional functions are provided in recent versions of
LinuxThreads (0.8 and up). Earlier releases did not provide
these optional components of the POSIX standard.

Even if pthread_attr_setstacksize() and
pthread_attr_setstackaddr() are now provided, we still
recommend that you do not use them unless you really have
strong reasons for doing so. The default stack allocation
strategy for LinuxThreads is nearly optimal: stacks start small
(4k) and automatically grow on demand to a fairly large limit
(2M). Moreover, there is no portable way to estimate the
stack requirements of a thread, so setting the stack size
yourself makes your program less reliable and non-portable.

However, is this behavior preserved under NPTL?

[Stephen]

Logged In: YES
user_id=87254

I read the same thing you did. There's no reason to believe
stacksize behaviour has changed with NPTL, espescialy if it
was considered 'nearly optimal'.

[Zoran Vasiljevic]

Logged In: YES
user_id=95086

I do not see any problems with this.
Moreover, I think it is a great help.

We have spent some time tuning the stacksize to a meaningful
level but this is pretty shitty job since you never know how
much is how little and vice versa.
Eventually, either you get a nasty core out of the blue,
or you're wasting memory.

I believe, Solaris uses quite large (1M) stacks per thread.
This is mostly not needed. Even with XOTcl and very
deep class nesting; we got to about 500-600 K of stack.

OTOH, Linux is more clever in that (no, it did not change
with NPTL) it dynamically manges the stack in increments.
So, for Linux I'd rather simply set stacksize to zero and
leave the thread-library manage this on its own accord.

I like the idea to leave the OS manage stack sizes where
appropriate, provided I can still influence it from outside.