многопоточный сервер

как именно? select в каждом треде?

> Вопрос - а надо ли мне это?

это зависит от того, как часто перегоняются какие-либо данные от клиента к серверу и обратно.

> Может не стоит заморачиваться и порождать на каждое входящее соединение отдельную нить?

может стоит написать тест, эмулирующий поведение клиентов и посмотреть на сколько сильно будет загружен сервер?

> Сколько потоков я смогу породить прежде чем системе поплохеет?

пишите тест. по крайней мере явно меньше, чем sysctl -e kernel.threads-max

нет, epoll в одном управляющем треде, в нем же происходит чтение из сокета, а обработка данных передается в тред обслуживающий группу соеднений(вот эта передача у меня и вызвает затруднения). Я хочу вызывать epoll(или select) в каждом треде,обслуживающем одно соединение, и там же делать всю обработку.

>это зависит от того, как часто перегоняются какие-либо данные от >клиента к серверу и обратно. >может стоит написать тест, эмулирующий поведение клиентов и посмотреть >на сколько сильно будет загружен сервер?

Боюсь что стоимость разработки такого теста превысит стоимость самого сервера :( Но, я попробую.

kernel.threads-max=131072 Я думаю, что мне хватит и десятой части.

имхо, если имеются чётко детерменированные сроки, и они не слишком велики, разумно сделать некоторую общую ф-ю/метод, предназначенный для конекта с клиентом. на первое время можно пусть делаются треды на каждый конект. если будет тормозить в реальных условиях, меняется только контекст данного метода/ф-ии.

Тебе нужно 10000 нитей. Если считать стек по 0.5Mб, то на это уйдет 5Гб.

Дальнейшее обсуждение имеет смысл?

Просто те люди, которые пытаются порождать сумасшедшее количество нитей, обычно используют стек столь же сумасшедшим образом.

Если автор топика к ним не относиться, то можно попытаться придумать еще какие-нибудь аргументы в пользу неразумности создания 10000 нитей.

> можно попытаться придумать еще какие-нибудь аргументы в пользу неразумности создания 10000 нитей.

Из ссылки выше:

4.
...
  Минусы:
    - В зависимости от OS, модель может быть как неэффективной (Linux,
      так как нить "весит" почти столько же, сколько и процесс), так и
      не масштабируемой с ростом числа процессоров (FreeBSD libc_r
      с user-space threads).
    - (Igor Khasilev) Если планируется обслуживать одновременно большое число
      подключенных клиентов (от тысячи и выше в зависимости от ОС) эта модель
      может оказаться нерабочей по причинам: расход адресного пространства
      на стек для каждой нити, большая нагрузка на планировщик и
      ограничение на общее число нитей в системе (особенно в случае
      1:1 модели). Иногда может спасти экстенсивный путь - переход на
      64-битные платформы.
    - Существенно затрудняется отладка. 

Интересно, как они "взвешивали"

Спроси у них сам. Я подозреваю, что имелось ввиду "с точки зрения планировщика"

Ну вот так всегда, сначала предлагают сменить язык, потом платформу, а потом и пол и сексуальную ориентацию. :)

>проде erlang как раз писался для того то-бы делать подобные вещи... я не уверен, что erlang не даст просадки производительности по сравнению с С++.

И вобще, коней на переправе не меняют.