合作框架中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 语言进行编码，它的goroutine就是你梦想的轻如羽毛的线程。

如果你想要很多协作线程，你可以研究一下Chicken Scheme 的实现技巧。