协作框架中Linux线程数量的实用限制

Question

因此，我知道我可以使用setrlimit和朋友来增加Linux进程的线程数量。根据this的说法，理论上线程数量的限制是由内存(大约100,000K左右)决定的。就我的使用而言，我正在研究如何以协作的方式使用FIFO scheduler，因此不需要关心虚假的上下文切换。我知道我可以将活动线程的数量限制为核心数量。我的问题是线程数量的实际限制是什么，在此之后，调度器中的假设开始无效。如果我保持一种真正的协作风格，额外的线程是“免费的”吗？任何案例研究或实际例子都会特别有趣。

Apache服务器似乎是最类似于这种情况的程序。有没有人有关于Apache在变得无用之前产生了多少线程的相关数字？

Related，但与Windows有关，抢占式代码。

Answer 1

我相信线程的数量是有限的。

1. 的可用内存(每个线程至少需要几个页面，并且经常需要许多页面，特别是用于堆栈和线程本地存储)。请参阅pthread_attr_setstacksize函数对其进行调优。线程堆栈空间达到1兆字节的情况并不少见。
2. 至少在Linux (NPTL，即current Glibc)和其他系统上使用，其中用户线程与内核线程相同，但内核可以调度的任务数量。

我猜在大多数Linux系统上，第二个限制比第一个更强。内核线程(在Linux上)是通过clone(2) Linux system call创建的。在旧的Unix或Linux内核中，任务的数量是硬连接的。它现在可能是可调的，但我猜它是几千，而不是数百万！

你应该考虑在Go language中编码，它的goroutines是你梦寐以求的轻量级线程。

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