所以我知道我可以使用 setrlimit 在 Linux 中增加进程的线程数和 friend 。根据this ，线程数的理论限制由内存决定(大约 100,000k)。对于我的使用，我正在研究使用 FIFO scheduler以合作的方式，所以虚假的上下文切换不是问题。我知道我可以将事件线程数限制为核心数。我的问题是线程数量的实际限制是多少，之后调度程序中的假设开始被破坏。如果我保持真正的合作风格，额外的线程是否“免费”？任何案例研究或实际例子都会特别有趣。
Apache 服务器似乎是与这种情况最相似的程序。有没有人知道 Apache 在变得无用之前产生了多少个线程？
Related ，但与 Windows 相关，先发制人的代码。
最佳答案
我相信线程的数量是有限的
根据可用内存(每个线程至少需要几个页面，通常需要很多页面，尤其是其堆栈和线程本地存储)。查看pthread_attr_setstacksize函数来调整它。每个线程堆栈空间为 1 兆字节并不少见。
至少在 Linux(NPTL，即当前的 Glibc)和其他系统上，用户线程与内核线程相同，但内核可以调度的任务数量相同。
我猜想在大多数 Linux 系统上，第二个限制比第一个要强。内核线程(在 Linux 上)是通过 clone(2) Linux system call 创建的.在旧的 Unix 或 Linux 内核中，任务的数量是固定的。它今天可能是可调的，但我猜它是几千，而不是几百万!
你应该考虑在 Go language 中编码, 它的 goroutines是您梦寐以求的轻如羽毛的线。
如果你想要很多协作线程，你可以查看Chicken Scheme实现技巧。
关于c++ - Linux 协作框架中线程数的实际限制，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8042041/