4 ms·

What are the advantages of low maximum stack size limits (given growable stacks)?

PerkinWarwick 5y ago
One obvious area is in small embedded systems. It's surprising how hard it can be to track down a stack-caused bug when you've got a bunch of interrupts banging on it. Generally it's a little unnerving to just pray that you've got enough stack given it's hidden usage and the possibility for things like recursion. Kind of a shame considering what a slick way it is to deal with memory leak avoidance.
- deleted 5y ago
  [deleted]
DrJokepu 5y ago
This is speculation, but maybe it catches unintended infinite recursion earlier? I’m willing to bet that the vast majority of stack overflows happen due to programming errors rather than genuine uses running out of stack.
- projektfu 5y ago
  This is the best answer I could think of. We have to assume the question is about Alpine Linux, not about embedded systems per se. Small thread stacks run out of space quickly (fail fast), help prevent a malicious process from gobbling up lots of VM, and force you to program in a style that doesn't use much stack space, although that's questionable because most memory leaks are heap-based. It's worth noting that the limits are adjustable on a per-package basis in Alpine based on the compiler-time link options.
jart 5y ago
Being able to build web servers with 10,000 threads w/ clean imperative code rather than event-driven yo-yo pattern finite state machines. It's what Google does. They limit stack size to 60kb for just that reason.
- floatboth 5y ago
  Kernel threads have tons of switching overhead so state machines are still better. Get your compiler to compile clean imperative code into them :) (okay, by "clean" I do mean littered with `.await`, but it's still structurally clean)
  - wahern 5y ago
    You don't need kernel scheduling for stackful threading. So-called green threading was common long before event-oriented asynchronous programming became popular with the advent of kqueue and epoll. See, e.g., https://www.gnu.org/software/pth/ https://www.gnu.org/software/pth/ That said, you can make kernel-aware user-controlled context switching much faster than it is currently: https://www.theregister.com/2020/08/10/google_scheduling_code_reaches_linux/ https://www.theregister.com/2020/08/10/google_scheduling_cod...

One obvious area is in small embedded systems. It's surprising how hard it can be to track down a stack-caused bug when you've got a bunch of interrupts banging on it. Generally it's a little unnerving to just pray that you've got enough stack given it's hidden usage and the possibility for things like recursion. Kind of a shame considering what a slick way it is to deal with memory leak avoidance.

deleted 5y ago
[deleted]

DrJokepu 5y ago

This is speculation, but maybe it catches unintended infinite recursion earlier? I’m willing to bet that the vast majority of stack overflows happen due to programming errors rather than genuine uses running out of stack.

projektfu 5y ago
This is the best answer I could think of. We have to assume the question is about Alpine Linux, not about embedded systems per se. Small thread stacks run out of space quickly (fail fast), help prevent a malicious process from gobbling up lots of VM, and force you to program in a style that doesn't use much stack space, although that's questionable because most memory leaks are heap-based. It's worth noting that the limits are adjustable on a per-package basis in Alpine based on the compiler-time link options.

jart 5y ago

Being able to build web servers with 10,000 threads w/ clean imperative code rather than event-driven yo-yo pattern finite state machines. It's what Google does. They limit stack size to 60kb for just that reason.

floatboth 5y ago
Kernel threads have tons of switching overhead so state machines are still better. Get your compiler to compile clean imperative code into them :) (okay, by "clean" I do mean littered with `.await`, but it's still structurally clean)
- wahern 5y ago
  You don't need kernel scheduling for stackful threading. So-called green threading was common long before event-oriented asynchronous programming became popular with the advent of kqueue and epoll. See, e.g., https://www.gnu.org/software/pth/ https://www.gnu.org/software/pth/ That said, you can make kernel-aware user-controlled context switching much faster than it is currently: https://www.theregister.com/2020/08/10/google_scheduling_code_reaches_linux/ https://www.theregister.com/2020/08/10/google_scheduling_cod...