為什麼棧的大小要有預設大小？

01-03

如果棧的大小隻要主存夠用就夠用，不就好了嗎？

贊同目前最高排名的徐釀泉陳宇的回答，因為棧空間要求連續。雖然我們用的是虛擬地址，但在一個進程內，地址範圍是確定的，一旦運行起來是不可改變的，所以當有多個線程存在的時候，不同線程之間的棧會把地址空間拆成若干的區域，線程之間的棧是不能互相侵犯的，尤其在32位環境下，4G的地址空間，刨除內核空間，實際的用戶空間並不大，一旦有多線程存在，必須保證線程棧互相隔離，不然無限增長的棧會導致不同線程之間的棧重疊。因此線程棧就有了大小的限制，其實對於單線程來說，棧的大小限制並不大，但多線程就麻煩了。

因為棧必須用固定的連續地址空間，所以必須提前分配好。即使有空閑內存、空閑地址空間，但是如果它不和當前的棧連在一起，當前線程也是不能用的。

（很多系統上，都有庫函數幫你調棧，用另一段地址作棧，實現coroutine。但是這需要特別的處理，不是直接用普通函數就可以的）

好問題，我搜了一下……

c++ - why is stack memory size so limited?

My intuition is the following. The stack is not as easy to manage as
the heap. The stack need to be stored in continuous memory locations.
This means that you cannot randomly allocate the stack as needed, but
you need to at least reserve virtual addresses for that purpose. The
larger the size of the reserved virtual address space, the fewer threads
you can create.

For example, a 32-bit application generally has a virtual address
space of 2GB. This means that if the stack size is 2MB (as default in
pthreads), then you can create a maximum of 1024 threads. This can be
small for applications such as web servers. Increasing the stack size
to, say, 100MB (i.e., you reserve 100MB, but do not necessarily
allocated 100MB to the stack immediately), would limit the number of
threads to about 20, which can be limiting even for simple GUI
applications.
A interesting question is, why do we still have this limit on 64-bit
platforms. I do not know the answer, but I assume that people are
already used to some "stack best practices": be careful to allocate huge
objects on the heap and, if needed, manually increase the stack size.
Therefore, nobody found it useful to add "huge" stack support on 64-bit
platforms.

Linux/GCC明明就支持segmented stack，大小不限，無非有性能代價就是了。

棧就是程序(task)在跑的時候用的一塊臨時空間。理論上在task suspend 之後給它換了也沒關係。並且也有人這樣干，不過通用系統裡邊這樣做有點得不償失的感覺。關鍵是搞不定棧上存的指向棧空間內的指針。