@richfelker can you give reference to how the current size of 80K was chosen? It seems to be causing a multitude of issues in lots of programs. When you say programs should request larger stack sizes when necessary, do you mean literally setting the stack size at runtime?
@deed02392, sorry I missed the previous request for comment. I don't think I have good records of exactly how, but basically what happened is that it was observed that various programs (git I remember especially) were crashing due to stack overflow in threads, and upon investigation of the code causing the crash, we found either buffers of size 64k or smaller (64k in git), or huge buffers like 1M+. Increasing to the latter was not deemed remotely acceptable, and increasing to something in between did not seem like it would help noticeably more applications (but would increase resource usage and decrease limit on number of threads that could be created at default stack size). 80k was chosen to leave room for signal handling or calling libc functions with mildly large stack requirements (like printf with float, or when llvm hoists the code such that it always uses as much stack as when printing floats).
> When you say programs should request larger stack sizes when necessary, do you mean literally setting the stack size at runtime?
I recall there was a discussion that a minimum bound should be the maximum theorectical size of a UDP packet, i.e. 65,507 bytes. That way you can call `recv` with a stack allocated buffer and then copy the actual size (usually after parsing) to some heap-allocated buffer: this may make use of various libc functions, so another minimum bound is size of startup code + size of udp buffer + size of libc functions + some extra stack frames. As it happened, ~80k fit this criteria (among others).