On 08/08/2014 09:28 AM, Konstantin Belousov wrote:
On Thu, Aug 07, 2014 at 04:18:12PM +0400, Ivan A. Kosarev wrote:

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.


freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to