On 08/08/2014 09:28 AM, Konstantin Belousov wrote: > On Thu, Aug 07, 2014 at 04:18:12PM +0400, Ivan A. Kosarev wrote: >> Hello, >> >> According to libthr's thr_init.c (the 9.2 version) init_main_thread() >> allocates s.c. "red zone" below the main stack in order to protect other >> stacks. The size of the main stack is determined by the >> _thr_stack_initial variable that is declared extern though it doesn't >> seem it can be changed. The value of the variable is set to 4M on 64-bit >> platforms which is obviously not sufficient for the most of real programs. >> >> Can anyone please confirm that there is no way to increase the stack >> size for the main thread and thus any program linked against libthr has >> only a few megabytes of stack memory for its main thread--whatever the >> system stack size (ulimit -s) is set to? > Yes, there is no way to change the main thread stack clamping. > Could you provide a reasonable use case for the 4MB stack ? Traversing trees with recursive functions or on-stack grammar parsers? > > Anyway, I somewhat sympathize to the idea to stop clamping the main > thread stack, and to not reuse it for other threads stack carving. > This also means that non-main threads stack allocator should stop > tracking the explicit location for the stacks and rely on vm mmap(2) > base selection instead. Yes, that would solve the problem. > I do not know the motivations why the current scheme of stacks allocation > was chosen. The changes do not look too involved. Thanks a lot. --Received on Fri Aug 08 2014 - 06:33:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:51 UTC