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


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

    Logged In: YES

    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:


    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?

  • Dossy Shiobara
    Dossy Shiobara

    • summary: Allow OS to manage stacksize automatically --> ns/threads "stacksize = 0" avoids setting explicit stacksize
  • Stephen

    Logged In: YES

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

  • Logged In: YES

    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.