Всякий раз, когда вы достигаете предела количества потоков - или, как уже упоминалось, исчерпываете адресное пространство виртуального процесса из-за количества потоков - вы ... делаете это неправильно. Другие темы не масштабируются. Особенно не во встроенном программировании. Вместо этого вы можете обрабатывать запросы в пуле потоков. Используйте poll(2) для обработки множества соединений с меньшим количеством потоков. Это довольно ухоженная территория, и библиотеки (например, ACE, asio) используют эту модель по уважительной причине
Модель «поток-на-запрос» в основном популярна из-за ее (кажущейся) простой конструкции.
Пока вы поддерживаете соединения в одном логическом потоке (иногда называемом strand ), реальной разницы, тем не менее, нет.
Кроме того, если обработка запроса не включает в себя операции блокировки, вы никогда не сможете сделать лучше, чем опрос и обработка в одном потоке: вы можете использовать функцию 'backlog' в bind / accept, чтобы позволить Ядро беспокоиться об ожидающих вас соединениях! (Примечание: предполагается, что одноядерный ЦП, на двухъядерном ЦП этот вид обработки будет оптимальным с одним потоком на ЦП)
Редактировать Добавление Re:
ulimit показывает, сколько потоков может обрабатывать ОС, верно? Если да, ulimit не решает мою проблему, потому что мое приложение использует ~ 10-15 потоков одновременно.
Если это так, вам действительно нужно проверить, что вы присоединяетесь или , правильно отсоединяя все потоки. Также подумайте об объектах синхронизации; если вы постоянно забываете вызывать соответствующие функции pthread * _destroy, вы выйдете за пределы даже без необходимости. Это, конечно, будет утечка ресурсов . Некоторые инструменты могут помочь вам заметить их (vlagrind / helgrind приходят на ум)