首先：对不起我的英语。 伙计们，我在POSIX套接字和/或pthreads上遇到了麻烦。我正在开发嵌入式设备（ARM9 CPU）。在设备上将工作多线程tcp服务器。它将能够处理大量传入连接。服务器从客户端获取连接并增加计数器变量（unsigned int counter）。客户端例程将在单独的线程中运行。所有客户端都将使用1个单例类实例（在此类中将打开和关闭相同的文件）。客户端使用文件，然后客户端线程关闭连接套接字，并调用pthread_exit（）。 所以，我的tcp服务器无法处理超过250个线程（计数器= 249 + 1（服务器线程）。而且我得到“资源暂时不可用”。有什么问题？
答案 0 :(得分：1)
每当你达到线程限制 - 或者由于线程数量而提到的虚拟进程地址空间耗尽 - 你做错了。更多线程无法扩展。特别是在进行嵌入式编程时。您可以在线程池上处理请求。使用poll(2)处理更少线程上的许多连接。这是一个很好的领域和图书馆（如ACE，asio）一直在充分利用这个模型
'每个请求的主题'模型主要受欢迎，因为它（感知）简单的设计。
只要您在单个逻辑线程（有时称为 strand ）上保持连接，就没有真正的区别。
另外，如果请求的处理不涉及阻塞操作，那么你毕竟不能比单个线程上的轮询和处理做得更好：你可以使用bind / accept的'backlog'功能来让内核担心待处理的连接！ （注意：假设一个单核CPU，在双核CPU上，这种处理最佳，每个CPU一个线程）
修改加法回复：
ulimit显示操作系统可以处理多少线程，对吧？如果是的话，ulimit并不能解决我的问题，因为我的应用程序同时使用~10-15个线程。
如果是这种情况，您应该仔细检查您是否正在加入或正确分离所有线程。还要想到同步对象;如果你一直忘记调用相关的pthread * _destroy函数，即使不需要它也会遇到限制。那当然是资源泄漏。有些工具可以帮助你发现它们（vlagrind / helgrind浮现在脑海中）
答案 1 :(得分：0)
使用 ulimit -n 检查文件系统句柄的数量。如果数字太低，您可以为当前会话增加它。
您也可以编辑/etc/security/limits.conf并设置永久限制
答案 2 :(得分：0)
通常，您在32位系统上遇到的第一个限制是使用默认堆栈大小时虚拟地址空间不足。
尝试在创建线程时显式指定堆栈大小（小于1 MB）或使用“ulimit -s”设置默认堆栈大小。
另请注意，您需要在线程中使用pthread_detach或pthread_join，以便释放所有资源。