4 ms·
The initial/main thread stack size is dynamic, it grows until it runs into another allocation (and these days there are guard pages and such). You can already u
by ploxiln 5y ago
The initial/main thread stack size is dynamic, it grows until it runs into another allocation (and these days there are guard pages and such). You can already use 128MB on the initial/main stack, even with musl-libc / Alpine linux (it needs to be linearly probed it if it's unreasonably huge, so the OS isn't surprised by a random memory access out in the middle of nowhere, but the compiler should do that automatically these days).
You can also request whatever stack size you need for additional threads when you create them, this has always been a good idea.
It's only the default stack size for non-main threads, if you don't specify it, which may be considered reasonably limited.
- masklinn 5y ago> The initial/main thread stack size is dynamic That seems doubtful, AFAIK all OS have a static allocation for the main thread, just one that is commonly (though not necessarily) much larger than what they give off-threads, as https://ariadne.space/2021/06/25/understanding-thread-stack-sizes-and-how-alpine-is-different/ https://ariadne.space/2021/06/25/understanding-thread-stack-... quotes Windows gives 1MB to all threads, while macOS or OpenBSD 4.6+ give 8MB to the main thread and 512k to off-threads. The former would not merit consideration if it was automatically increased. > it grows until it runs into another allocation Which it won't because vmem. > and these days there are guard pages and such That just makes the access segfault if the stack allocation is not large enough to straight jump over the guard page.
- ploxiln 5y agoI'm not so familiar with other operating systems, but on Linux and presumably other unixes, the only thing holding back the initial/main "process stack" is ulimit. Try "ulimit -s unlimited". (On macOS that increases it from 8MB to 64MB, but on linux it seems to really go unlimited)