合作框架中Linux中線程數的實際限制

Question

所以我知道我可以使用setrlimit和朋友增加Linux中進程的線程數。 根據這一點 ，線程數的理論限制由內存決定（大約100,000k）。 對於我的使用，我正在考慮以協作方式使用FIFO調度程序 ，因此虛假的上下文切換不是一個問題。 我知道我可以將活動線程數限制為核心數。 我的問題是線程數量的實際限制是什么，之后調度程序中的假設開始被消除。 如果我保持真正的合作風格是額外的線程“免費”？ 研究的任何案例或實際的例子都會特別有趣。

Apache服務器似乎是最適合這種情況的程序。 有沒有人有任何數字與他們在變得無用之前看到Apache產生了多少線程相關？

相關 ，但與Windows，先發制人代碼有關。

Answer 1

我相信線程數量有限

1. 通過可用內存（每個線程至少需要幾個頁面，通常需要很多頁面，特別是它的堆棧和線程本地存儲）。 請參閱pthread_attr_setstacksize函數來調整它。 每個兆字節的線程堆棧空間並不罕見。

2. 至少在Linux（NPTL，即當前的Glibc）和其他系統中，用戶線程與內核線程相同，但內核可以調度的任務數量。

我想在大多數Linux系統上，第二個限制比第一個更強。 內核線程（在Linux上）是通過clone(2) Linux系統調用創建的 。 在舊的Unix或Linux內核中，任務數量是硬連線的。 它今天可能是可調的，但我猜它是成千上萬，而不是數百萬！

你應該考慮使用Go語言進行編碼，它的goroutines是你夢寐以求的輕盈線程。

如果你想要很多合作線程，你可以查看Chicken Scheme實現技巧。