Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding thread stack sizes and how Alpine is different

ariadne.space

Post reply on HN
Print view View original

41–50 of 81 posts

Re: Understanding thread stack sizes and how Alpine is different

#41

Post by formerly_proven »

tyingq wrote: post #9
moring wrote: post #6

> In general, it is my opinion that if your program is crashing on Alpine, it is because your program is dependent on behavior that is not guaranteed to actually exist, which means your program is not actually portable. When it comes to this kind of dependency, the typical issue has to deal with the thread stack size limit. The wording sounds as if it is trying to assign blame for the problem. What, then, is the guar…

Guessing PTHREAD_STACK_MIN

> Minimum Acceptable Value: 0

Thanks, posix.

Re: Understanding thread stack sizes and how Alpine is different

#42

Post by dnautics »

sys_64738 wrote: post #2

In other words, use heap space and not stack space. This is pretty elementary in C programming.

this is too reductive. Usually stack space is faster because you will have fewer cache misses.

future languages will be able to suss this out at compile-time: https://github.com/ziglang/zig/blob/2ac769eab9b7dba4cd38e5de...

Re: Understanding thread stack sizes and how Alpine is different

#43

Post by ynik »

sys_64738 wrote: post #2

In other words, use heap space and not stack space. This is pretty elementary in C programming.

It's a bit ridiculous to complicate recursive algorithms just because the stack sizes haven't been increased in the past 3 decades.

Nowadays we have at least 48bit virtual address space available; what's the harm in giving each thread a full GB of stack?

Re: Understanding thread stack sizes and how Alpine is different

#45

Post by sys_64738 »

ynik wrote: post #43
sys_64738 wrote: post #2

In other words, use heap space and not stack space. This is pretty elementary in C programming.

It's a bit ridiculous to complicate recursive algorithms just because the stack sizes haven't been increased in the past 3 decades. Nowadays we have at least 48bit virtual address space available; what's the harm in giving each thread a full GB of stack?

Generally recursion is not something you want in production code. It's cute for academia when studying algorithms but where there's an iterative alternative that should be used.

Re: Understanding thread stack sizes and how Alpine is different

#46

Post by sys_64738 »

dnautics wrote: post #42
sys_64738 wrote: post #2

In other words, use heap space and not stack space. This is pretty elementary in C programming.

this is too reductive. Usually stack space is faster because you will have fewer cache misses. future languages will be able to suss this out at compile-time: https://github.com/ziglang/zig/blob/2ac769eab9b7dba4cd38e5de...

If speed issues then it sounds like this is critical code path that is sensitive to time. You'd be looking for alternative data structures at that point so this point would be moot.

Re: Understanding thread stack sizes and how Alpine is different

#47

Post by kstenerud »

sys_64738 wrote: post #2

In other words, use heap space and not stack space. This is pretty elementary in C programming.

That might have been true in the old days when memory wasn't the bottleneck, but in today's world where a cache miss is catastrophic, it makes MUCH more sense to use stack space where you can. This also has the side effect of facilitating idempotent functions and function purity in general.

No sense in clinging to old world ideals when they no longer make sense.

Re: Understanding thread stack sizes and how Alpine is different

#48

Post by lanstin »

creata wrote: post #24
viraptor wrote: post #16

Earlier quoted context omitted.

You have 2 options: either your functions are recursive and you can hope and pray, or they're not and you can figure out which of your functions are the bottom of the call graph. In those leaf functions you can check &local_var and compare it to pthread_attr_getstack(pthread_getattr_np()). (Of course that's not precise for many reasons.) > And how do you design a program to have a deterministic maximum call stack dep…

> You have 2 options: either your functions are recursive and you can hope and pray Or you can try to figure out the maximum number of times it'll recurse: for example, the height of a red-black tree with less than 2^64 nodes is less than 128, iirc.

One rather quickly runs into halting-problem type issues, especially in the function dispatch method. Imagine a DSL that does stuff, and is implemented by function pointers in the parser/interpreter, and then the question becomes one of program inputs. In any case, having such a small limit is crazy, and defending it with references to correctness smells of Ulrich Drepper and the memmove issue. The whole "sucks less" movement is a little too focused on purity for my taste. The only time I'm sad when I look at my memory usage on my personal laptop is when I have unused memory. Please, pre-fetch some news.ycombinator, cache some more inodes for my next ncdu or find command; I have already paid for the memory, not using it is silly. Sure, we software engineers get lazy, but, except in AWS, use all your memory, all your processors upto throttling, all the time. Why not?

I remember one day in the 90s counting out like max address len and max zip code len and so and trying to figure out how long to make my target stack allocated buffer, and i was like fuck it, I have more important things to do, all my stack buffers are hence forth 65536 bytes long.

Re: Understanding thread stack sizes and how Alpine is different

#49

Post by ariadneconill »

kstenerud wrote: post #47
sys_64738 wrote: post #2

In other words, use heap space and not stack space. This is pretty elementary in C programming.

That might have been true in the old days when memory wasn't the bottleneck, but in today's world where a cache miss is catastrophic, it makes MUCH more sense to use stack space where you can. This also has the side effect of facilitating idempotent functions and function purity in general. No sense in clinging to old world ideals when they no longer make sense.

That is certainly a take.

Storing small data, like function-local ints, pointers, etc, on the stack is beneficial due to L1$ prefetching semantics, but storing a 512KB scratchpad on the stack (which is what the article is about) will totally trash your L1$ and you'll have MORE cache misses than you would if that scratchpad was not on the stack.

Re: Understanding thread stack sizes and how Alpine is different

#50

Post by arghwhat »

kstenerud wrote: post #34

Yeah, it sucks that programs crash on your system, but this is the way of things: The popular systems get targeted and tested in-depth, the less popular systems not so much. This is NOT the developer's fault; this is pragmatism . And so the mountain must come to Mohamed. Increase Alpine's default stack size to something more in-line with the big boys.

No, they should keep their low stack size to the benefit of everyone.

Diversity helps discover what is fundamentally a broken and fragile assumption that a dynamic property will always have some value. An assumption that can fail anywhere, including on the OS that was initially targeted, and will fail the moment another OS is targeted.

The developer should fix their broken assumption, but is entirely free to do so by taking control of the value at link time.

Post reply on HN