Understanding thread stack sizes and how Alpine is different
1–10 of 81 posts
Re: Understanding thread stack sizes and how Alpine is different
#2In other words, use heap space and not stack space. This is pretty elementary in C programming.
Re: Understanding thread stack sizes and how Alpine is different
#3In other words, use heap space and not stack space. This is pretty elementary in C programming.
Sure, but 128 kB is really small even if you do that properly.
Seems like it would be more sensible if the stack space could just grow when required. Surely not that difficult?
Re: Understanding thread stack sizes and how Alpine is different
#4In other words, use heap space and not stack space. This is pretty elementary in C programming.
I'd say "be aware of stack sizes". If you can get away with just the appropriately sized stack in a thread, that's a nice performance gain over dealing with multithreading heap allocators.
Re: Understanding thread stack sizes and how Alpine is different
#5In other words, use heap space and not stack space. This is pretty elementary in C programming.
Sure, but 128 kB is really small even if you do that properly. Seems like it would be more sensible if the stack space could just grow when required. Surely not that difficult?
The main thread already does that. The thread stack does not. It probably made sense on 32b with relatively limited address space... But I'm curious why we're not applying that to all threads on 64b. Reserving a few 10MB of address space per thread shouldn't be a big issue, right? (Without actually mapping those pages)
Re: Understanding thread stack sizes and how Alpine is different
#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 guaranteed thread stack size? A developer would obviously need to know this (and other things such as the amount of stack size required by variables, parameters and frames) to not fall into this trap of writing non-portable programs.
Re: Understanding thread stack sizes and how Alpine is different
#7How can you write a program that runs without at least some guaranteed stack size? Are you at fault if you program doesn't run in a 1kb stack? And how do you work out what stack size your program takes from looking at the source code?
I guess make sure your required stack size is not a function of input, and test against a minimum stack size.
Re: Understanding thread stack sizes and how Alpine is different
#8In other words, use heap space and not stack space. This is pretty elementary in C programming.
Sure, but 128 kB is really small even if you do that properly. Seems like it would be more sensible if the stack space could just grow when required. Surely not that difficult?
It is easy for a single threaded program, but since each thread has it's own part of the stack, it would be non-trivial for a multithreaded program.
Re: Understanding thread stack sizes and how Alpine is different
#9> 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
Re: Understanding thread stack sizes and how Alpine is different
#10How can you write a program that runs without at least some guaranteed stack size? Are you at fault if you program doesn't run in a 1kb stack? And how do you work out what stack size your program takes from looking at the source code? I guess make sure your required stack size is not a function of input, and test against a minimum stack size.
Unless you do alloca() or dynamically sized local arrays, you can measure your stack usage in the deepest call stack. Add some space in each frame for potential instrumentation and you have your minimum.
Keep in mind that this is just for thread stacks - you can set the size for them yourself, so ideally you'd always do it. Then a guaranteed minimum size becomes irrelevant.