所以我知道我可以使用setrlimit和朋友增加Linux中进程的线程数。根据{{3}}，线程数的理论限制由内存决定（大约100,000k）。对于我的使用，我正在研究以合作方式使用this，因此虚假的上下文切换不是问题。我知道我可以将活动线程数限制为核心数。我的问题是线程数量的实际限制是什么，之后调度程序中的假设开始被消除。如果我保持真正的合作风格是额外的线程“免费”？研究的任何案例或实际的例子都会特别有趣。
Apache服务器似乎是最适合这种情况的程序。有没有人有任何数字与他们看到Apache在变得无用之前产生了多少线程有关？
FIFO scheduler，但与Windows，先发制人代码有关。
答案 0 :(得分：2)
我认为线程数量有限
由可用内存（每个线程至少需要几个页面，通常是其中许多页面，特别是其堆栈和线程本地存储）。请参阅pthread_attr_setstacksize功能进行调整。每个兆字节的线程堆栈空间并不罕见。
至少在Linux（NPTL，即当前的Glibc）和其他系统中，用户线程与内核线程相同，但内核可以安排的任务数量。
我猜想在大多数Linux系统上，第二个限制比第一个更强。内核线程（在Linux上）是通过clone(2) Linux system call创建的。在旧的Unix或Linux内核中，任务数量是硬连线的。它今天可能是可调的，但我猜它是成千上万，而不是数百万！
你应该考虑在Go language编码，它的goroutines是你梦寐以求的光线。
如果你想要很多合作线程，你可以查看Chicken Scheme实现技巧。