这是什么意思“主线程可以动态地种植其堆栈”。
在 pthread_at_attr_settacksize（）（
在创建线程时，线程的堆栈大小是固定的。我对linux pthread的理解只有主线程才能动态生长其堆栈。
主线程堆栈大小仅限于ulimit -s在主线程创建上值。尽管它按照堆栈使用的需求将PHY映射到app，但尺寸不再长大了。
动态增长在这里意味着什么？它是否意味着主线程堆栈大小可以超过ulimit -s？
On man page for pthread_attr_setstacksize()
A thread's stack size is fixed at the time of thread creation. Only the main thread can dynamically grow its stack.
My understanding on linux pthread, the main thread stack size is limited to ulimit -s value on main thread creating. Although it maps phy to virt on demand of stack usage, the size is not grown any more.
What does the dynamically grow mean here? Does it imply main thread stack size can grow exceeding ulimit -s?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
ulimit -s设置的值（akasetrlimit（rlimit_stack，...）），通常为8 mb，默认为8 mb，是 maximaim尺寸。最初，将分配和映射少量的虚拟内存（也许只有几个KB）。当堆栈的生长大于实际分配的数量时，它会触发页面故障。然后，内核将当前用法与Rlimit中设置的最大值进行比较。如果尚未达到最大值，则内核会分配更多的虚拟内存页面并将其映射到位，然后将控制返回到该过程。这是完全透明的。如果达到最大值，它将用sigsegv杀死该过程。如果系统不得不为每个过程保留完整的8 MB虚拟内存，那么大多数人使用的时间却少得多，那将是效率的。通过仅根据需要分配它，即使机器只有64 MB的内存 +交换总计，您仍然可以使用数百个过程，每个过程都有8 MB堆栈限制。这是超越的一种形式。
还要记住，一个过程可以在运行时调用
setrlimit本身，并增加其自身的最大堆栈尺寸，只要没有其他绘制到该地址空间。主线程的堆栈传统上位于虚拟内存的顶部附近，其他所有内容都在底部附近，因此之间有很多免费的地址空间，因此通常可以将最大值超过其最初的8 MB限制。但是，其他线程一定必须在其他地方分配，并且实际上不可能确保有很多免费的地址空间可以供他们发展。The value set by
ulimit -s(akasetrlimit(RLIMIT_STACK, ...)), usually 8 MB by default, is the maximum stack size. Initially, a much smaller amount of virtual memory will be allocated and mapped (perhaps just a few kb). When the stack grows larger than the amount actually allocated, it triggers a page fault. The kernel then compares the current usage with the maximum value set in the rlimit. If the maximum has not been reached, the kernel allocates more pages of virtual memory and maps them into place, then returns control to the process; this is completely transparent. If the maximum is reached, it kills the process with SIGSEGV.It would be inefficient if the system had to reserve a full 8 MB of virtual memory for every process, when most will use far less. By allocating it only as needed, you can still have hundreds of processes, each with an 8 MB stack limit, even if the machine has only (let's say) 64 MB of memory + swap total. It's a form of overcommitment.
Also keep in mind that a process can call
setrlimititself at run time and increase its own maximum stack size, so long as nothing else has been mapped into that address space. The main thread's stack is traditionally located near the top of virtual memory, with everything else near the bottom, so that there is a lot of free address space in between, and so increasing the maximum beyond its initial 8 MB limit is usually possible. However, the stacks of other threads necessarily must be allocated elsewhere, and it is not really possible to ensure that there is a lot of free address space for them to grow into.