4 ms·

> 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 actuall

by moring 5y ago

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

nsajko 5y ago
> The wording sounds as if it is trying to assign blame for the problem. Yes. Sadly, people often write incorrect programs. > What, then, is the guaranteed thread stack size? I can't be bothered to look up the POSIX guarantees, the gist of it anyway is that it depends on the application developer and system administrator. > 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. If you're not going to calculate the exact requirements (probably unnecessary), guess/measure a number of bytes and allocate a stack that's 50 or 100 times greater than that. That's better than ignoring the existence of the stack, anyway.
tyingq 5y ago
Guessing PTHREAD_STACK_MIN
- formerly_proven 5y ago
  > Minimum Acceptable Value: 0 Thanks, posix.
lonjil 5y ago
> What, then, is the guaranteed thread stack size? If you need a big stack, you can just ask pthread to give you one.
ElViajero 5y ago
> The wording sounds as if it is trying to assign blame for the problem. Yes. It sound like someone that have been in a million discussion about why "that your program crashes is not a bug in our operating system". Many people, even engineers, expect things to behave as they usually do instead of behave as specified. So, I can imagine how all that discussions go.

by moring 5y ago

nsajko 5y ago

> The wording sounds as if it is trying to assign blame for the problem. Yes. Sadly, people often write incorrect programs. > What, then, is the guaranteed thread stack size? I can't be bothered to look up the POSIX guarantees, the gist of it anyway is that it depends on the application developer and system administrator. > 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. If you're not going to calculate the exact requirements (probably unnecessary), guess/measure a number of bytes and allocate a stack that's 50 or 100 times greater than that. That's better than ignoring the existence of the stack, anyway.

tyingq 5y ago

Guessing PTHREAD_STACK_MIN

formerly_proven 5y ago
> Minimum Acceptable Value: 0 Thanks, posix.

lonjil 5y ago

> What, then, is the guaranteed thread stack size? If you need a big stack, you can just ask pthread to give you one.

ElViajero 5y ago

> The wording sounds as if it is trying to assign blame for the problem. Yes. It sound like someone that have been in a million discussion about why "that your program crashes is not a bug in our operating system". Many people, even engineers, expect things to behave as they usually do instead of behave as specified. So, I can imagine how all that discussions go.